使用rinetd解决阿里云和腾讯云之间的探针丢包掉线问题
本文发布于 997 天前,最后更新于 723 天前,其内容可能已经过时,请以实际发展为准。如图片或链接失效,请留言说明。 你真的收不住你的洛阳铲了吗?

作为MJJ大军中的一员我拥有好几台服务器,为查看服务器的运行状态所以自建了探针页面,和博客主站在同一个HK腾讯轻量云上。大多数服务器都能正常地与探针服务器建立连接,但唯独去年双十一买回来吃灰的阿里云北京轻量不太行,探针是能挂上,但是会经常显示断开,再又连接上,循环往复。然后就一直没放到探针列表里。

解决问题就要先找到问题

为了找到解决方案,先做了一些测试:

Ping

最常用的检验网络连通性的方式,现在是1月18日晚上7点,从阿里云向腾讯云ping 100个包看看:

--- 43.***.***.*** ping statistics ---
100 packets transmitted, 65 received, 35% packet loss, time 99606ms
rtt min/avg/max/mdev = 43.992/44.119/44.389/0.066 ms

丢包率显然是高到无法接受,这也验证了我最初的猜测。即使刨去近期以来腾讯云HK到内地的丢包率显著提升,之前在闲时也有25%的丢包,这次ping中间也是经常出现3-4个连续的丢包。

Traceroute

# traceroute -I -A 43.***.***.***
traceroute to 43.***.***.*** (43.***.***.***), 30 hops max, 60 byte packets
 1  * * *
 2  * * *
 3  11.97.25.181 (11.97.25.181) [AS749]  1.070 ms  4.529 ms  4.526 ms
 4  10.54.181.14 (10.54.181.14) [*]  1.053 ms  1.048 ms  1.046 ms
 5  10.102.234.242 (10.102.234.242) [*]  2.345 ms  2.312 ms  2.363 ms
 6  10.102.34.229 (10.102.34.229) [*]  2.036 ms  2.086 ms  2.034 ms
 7  106.38.196.25 (106.38.196.25) [AS23724]  3.470 ms  3.924 ms  3.393 ms
 8  * * *
 9  202.97.53.18 (202.97.53.18) [AS4134]  22.346 ms  22.312 ms  21.103 ms
10  202.97.12.126 (202.97.12.126) [AS4134]  5.067 ms  5.468 ms  5.416 ms
11  202.97.39.106 (202.97.39.106) [AS4134]  58.949 ms  62.623 ms  61.901 ms
12  203.215.232.194 (203.215.232.194) [AS4134/AS38281]  276.535 ms *  278.196 ms
13  * * *
14  * * *
15  * * *
16  * * *
17  * 43.***.***.*** (43.***.***.***) [AS132203]  44.131 ms *

其中-I是使用ICMP协议进行Traceroute,因为Linux下Traceroute默认是向一个端口范围发UDP包,而我机器开着安全组,是trace不到最终结果的。-A是显示途经网关的ASN信息,可以看出是走了谁家的线路,这里发现默认是走了电信163网(AS4134),电信的骨干网和出口都比较拥挤是众所周知的,但达到这个水平显然是有问题。

因为ServerStatus只需要35601一个端口,需要的是连接基本稳定,但对延迟和带宽要求不是很大。因此想到使用一台阿里云去程和腾讯云回程都比较稳定的机器做端口转发。

配置

登陆到用来转发端口的机器(跳板机),用的是我那台BuyVM的机器,系统是Debian 11,所需要的工具rinetd在官方源里面就有:

# apt update
# apt install rinetd

配置也相当的简单:

# nano /etc/rinetd.conf
# forwarding rules come here
#
# you may specify allow and deny rules after a specific forwarding rule
# to apply to only that forwarding rule
#
# bindadress    bindport  connectaddress  connectport

从左到右依次是跳板机的IP、跳板机转发的目标端口、被转发的主机的IP和要转发的端口,中间用空格隔开。例:

192.168.0.1 36501 192.168.0.2 36501

跳板机的IP这里是192.168.0.1,转发来自192.168.0.2的35601端口到自己的35601端口。如果跳板机有多个IP,则客户机只有使用这里的bindaddress访问目标端口才有效,如果要让所有IP都能访问,可以把bindaddress设置成0.0.0.0

启用服务:

# systemctl enable --now rinetd
# systemctl restart rinetd

然后在阿里云的机器上编辑status-client的服务配置文件,把目标IP和端口改成跳板机的:

# nano /usr/lib/systemd/system/status-client.service

转到[Service]下面的ExecStart项,用新的IP和端口进行替换

ExecStart=/opt/status-client/status-client -interval 1.5 -dsn="用户名:密码@192.168.0.1:35601"

然后启用ServerStatus服务:

# systemctl enable --now status-client

然后就打开探针页面等着吧,确实不再出现掉线的问题了,可以愉快地挂探针了

$ EOF.

本文标题:使用rinetd解决阿里云和腾讯云之间的探针丢包掉线问题
本文链接:https://www.jyzb01.com/2022/01/18/packet-loss-solution-with-rinetd/
授权协议:署名-非商业性使用-相同方式共享 4.0 (CC BY-NC-SA 4.0)
转载或引用请标明出处为本站,不得用于商业用途,并以相同协议共享。严禁CSDN/采集站采集转载。
暂无评论

发送评论 编辑评论

|´・ω・)ノ
ヾ(≧∇≦*)ゝ
(☆ω☆)
(╯‵□′)╯︵┴─┴
 ̄﹃ ̄
(/ω\)
∠( ᐛ 」∠)_
(๑•̀ㅁ•́ฅ)
→_→
୧(๑•̀⌄•́๑)૭
٩(ˊᗜˋ*)و
(ノ°ο°)ノ
(´இ皿இ`)
⌇●﹏●⌇
(ฅ´ω`ฅ)
(╯°A°)╯︵○○○
φ( ̄∇ ̄o)
ヾ(´・ ・`。)ノ"
( ง ᵒ̌皿ᵒ̌)ง⁼³₌₃
(ó﹏ò。)
Σ(っ °Д °;)っ
( ,,´・ω・)ノ"(´っω・`。)
╮(╯▽╰)╭
o(*////▽////*)q
>﹏<
( ๑´•ω•) "(ㆆᴗㆆ)
😂
😀
😅
😊
🙂
🙃
😌
😍
😘
😜
😝
😏
😒
🙄
😳
😡
😔
😫
😱
😭
💩
👻
🙌
🖕
👍
👫
👬
👭
🌚
🌝
🙈
💊
😶
🙏
🍦
🍉
😣
Source: github.com/k4yt3x/flowerhd
颜文字
Emoji
小恐龙
花!
上一篇
下一篇