服务器维护记录 | maxuewei2 的博客

前言

路由器的 WAN 口地址为 59.72.109.253/24，LAN 口地址为 192.168.1.1/8。
服务器 IP 为 192.168.1.110/8，在路由器的 DHCP 服务器菜单下的静态地址保留项目中设置了静态地址保留。
我卡位机器 IP 为 192.168.1.128/8，也同样做了静态地址保留。
服务器有 SSH 服务和 HTTP 服务需要连接到外网，于是在路由器的转发规则菜单下的虚拟服务器项目中做了端口映射。

问题 1

网络问题导致 ssh 经常卡死，症状是登录后经常打字没有反应，等几秒乃至几十秒后才有反应，之前输入的东西这时也才显示出来。
这个问题在 2019 年 10 月底出现，到 11 月初李鑫初步解决，解决方式是使用 arp-scan -l 命令不断在局域网内发 arp 包。
具体方式是建立一个脚本，假设叫 arp.sh，内容为

#!/bin/bash
i=0
while true
do
	arp-scan -l 
	let i++
	echo "new arp started"
	echo i
done
exit

然后设置一个开机自启的脚本，内容是

1 2	#!/bin/bash nohup bash /arp.sh &

这样即可解决上述 ssh 经常卡死的问题。

问题 2

ssh 连接失败，症状是服务器网络正常，但 ssh 客户端登录时显示 connection reset by peer 或者 connection reset by {ip} port 22。
问题出现于 2020.1.8。

解决方式：
先在服务器上 sudo service ssh stop，
然后 sudo mkdir /run/sshd，
然后 sudo /usr/sbin/sshd -d，
然后在 ssh 客户端上尝试连接服务器，
此时服务器应该会显示在接受客户端的连接，并输出一些信息，其中会有错误信息，于是可根据错误信息排查问题或在网上搜索该错误信息查找解决方案。

我遇到的问题是 No supported key exchange algorithms [preauth]，
在网上搜索后发现这个问题是因为 /etc/ssh 下文件的权限有问题，正确的权限应该是对于 key 文件只有 root 有读写权限，其他用户什么权限都没有，即权限码为 600，而对于 pub 文件，仅 root 有读写权限，其他用户只有读权限，即权限码为 644。
在服务器上执行执行 ll /etc/ssh，果然发现权限不对，所有文件都是 755 权限。
于是

1
2
3

cd /etc/ssh
sudo chmod 600 ssh_host_*
sudo chmod 644 *.pub

然后 sudo service ssh start。
问题解决。

问题 3

2020.1.8 晚在解决问题 2 时，远程登录服务器以及我位置的机器(192.168.1.128) 都出现 ssh 间歇性卡死的问题，即问题 1 中的症状。
于是使用问题 1 的解决方式解决，192.168.1.128 机器恢复正常，服务器 ssh 依然间歇性卡死。
ssh 卡死时服务器上部署的网站也打不开，同时服务器连接外网也很容易打不开或容易断或速度慢。
ping 百度时有 Temporary failure in name resolution 错误或丢包很多，ping 网关 192.168.1.1 时，丢包也很严重，但 ping 局域网内其他机器如 192.168.1.128 时就没有问题。
用局域网内其他机器 ping 网关 192.168.1.1 时没有问题，ping 服务器时也没有问题，ping 百度时也没有问题。

以前搜过 ssh 卡死及 ping 时丢包的问题，见过一些回答说可能是因为局域网内有其他跟本机 IP 相同的机器，
于是之前也在 192.168.1.128 机器上使用过 arping -I enp3s0 192.168.1.110 命令查看是否有多台同 IP 的机器，然而并没有。
这次遇到 ping 网关丢包的问题之后又执行了 arping ，依然没有其他机器。

于是设置了防火墙，卸载了 Network-manager，用 netplan 设置了静态地址，修改了 /etc/resolv.conf，设置了路由表，依然没有作用。
最终一筹莫展时试着在路由器上给服务器重新分配了静态地址，由 192.168.1.110 改为了 192.168.1.198，在 netplan 中也做了相应的修改，然后 sudo netplan apply，
重新 ssh 登录后，再 ping 网关，发现正常了，ping 百度也正常了。

所以还是因为 IP 地址重复的问题？遂在路由器设置中进行了一番查找，最终在 IP 与 MAC 绑定菜单下的 ARP 映射表中发现有一个不是服务器网卡的 MAC 地址对应着 192.168.1.110，
所以目前只能解释为因为路由器的 arp 缓存中有这么一条记录，服务器才丢包的吧。而因为我执行 arping 的时候，这台设备并不在线，所以 arping 就没有什么异常。
另，这台该死的设备的 MAC 为 04-D9-F5-F5-4D-85。

另，若仅修改绑定的静态地址，不运行 arp-scan，也会依然正常吗？过几天试一试。

END

2020.1.9 3:45