没有安全的语言,只有不安全的人
cloudflare全球大崩盘大家都知道了,结果就是这么个简单原因,发现一个数据库返回值不对,程序自己给panic掉了。。
这在任何一个公司都不允许的事情居然在cloudflare这种公司发生了。
rust很安全?一个屌毛开发就可以让它原地爆炸,话说,cloudflare审核代码、代码评议难道也不存在吗?
太草台了,甚至草台过我。

cloudflare全球大崩盘大家都知道了,结果就是这么个简单原因,发现一个数据库返回值不对,程序自己给panic掉了。。
这在任何一个公司都不允许的事情居然在cloudflare这种公司发生了。
rust很安全?一个屌毛开发就可以让它原地爆炸,话说,cloudflare审核代码、代码评议难道也不存在吗?
太草台了,甚至草台过我。

很多年前,那个时候我刚才开始用unix系,当时用freebsd。
freebsd的理念是,安全!网络安全,数据安全!一切都要安全。只是不能忍受的是,硬盘太慢了,稍微负荷重一点系统就卡在io上响应非常缓慢,更严重的是,io引起恶性循环最终服务器宕机,被迫断电重启后那强制fsck动不动需要执行几天,而且还不能够中断!安全,都是为了安全,因为freebsd使用了同步io,就是所有数据都是实时同步刷新到硬盘。
后来有一天,我用了freebsd批判的很不安全的linux,突然发现,天啊,我的服务器尽然可以这么快!同样负荷下系统竟然如此的流畅!
一下顿悟了,与其动不动卡死及长时间停机,我还不如冒点风险,接受这“不安全”的异步io。服务器硬件原因宕机其实是小概率事件,为了防止小概率事件而选择另一个大概率/必然的恶性事件,不值得! 现在freebsd已经可以认为是事实上早已死亡,而linux生机勃勃,用户的选择就说明了一切。
今天想到这个问题是因为我在习惯性的为服务器设置raid1,然后突然想到,我为什么要设raid1而不是0呢?
数据我都是实时异地备份的,硬盘可能一年都不会挂一次,为了这低概率事件,我要忍受硬盘速度慢一半空间少一半,这不和freebsd那情况一样吗?我又顿悟了。
众所周知,OVH在后台管理面板中显示/128,但其实是提供的/64。不过,OVH默认仅将 ::1 路由到了网口,这就是/128的缘由。
用NDPPD是解决之道,原理什么就不扯了,直接贴命令步骤吧。 本文由GPT友情提供技术支持,我自己亲身实测在Debian13上完全好用。以前的一些方法长时间空闲时会中断路由或者空闲后需要好几秒才能恢复完成第一次连接的问题,用本方法都不存在。
apt update
apt install ndppd -y
cat <<EOF >/etc/sysctl.d/99-ipv6-proxy.conf
net.ipv6.conf.all.forwarding=1
net.ipv6.conf.default.forwarding=1
net.ipv6.conf.all.proxy_ndp=1
net.ipv6.conf.default.proxy_ndp=1
EOF
sysctl --system
cat >/etc/ndppd.conf <<'EOF'
route-ttl 30000
proxy eno1 { #注意改成你的外网网卡
router yes
ttl 30000
rule 你的ipv6::/64 { #比如面板的是 A:B:C:D::1/128,这里就填 A:B:C:D::/64
static
}
}
EOF
systemctl enable --now ndppd
systemctl restart ndppd
cat << 'EOF' > /usr/local/bin/ipv6-keepalive.sh
#!/bin/sh
while true; do
ip -6 neigh show >/dev/null 2>&1
sleep 60
done
EOF
chmod +x /usr/local/bin/ipv6-keepalive.sh
cat << 'EOF' > /etc/systemd/system/ipv6-keepalive.service
[Unit]
Description=IPv6 NDP Keepalive
After=network.target
[Service]
ExecStart=/usr/local/bin/ipv6-keepalive.sh
Restart=always
[Install]
WantedBy=multi-user.target
EOF
systemctl daemon-reload
systemctl enable --now ipv6-keepalive.service
搞定。现在,你可以在主机中,或者在虚拟机中任意分配/64子网地址,NDPPD就会将其自动宣告出去。
这个博客现在就是Cloudflare通过IPV6回源。好处是啥?这样直接可以回源到虚拟机80/443上,因为是个独立的IP,而如果通过V4则需要在主机上做额外的7层转发。
这几天上网卡死了,访问网站十个有九个都卡,包括我这倒霉的博客我自己也很难打开。但只限于访问网站,ssh和网络测试等又没有任何问题(但speedtest.net也很难打开),路由器和chrome都快被我重启得冒烟了。
今天终于发现,是cloudflare卡了,我太信任它了,居然都没去检查它。结果就是,同城ping居然能用掉100多ms。例子只是1.1.1.1,其实所有的节点ip都一样卡。
知道问题就简单了,因为要回国,我机器常年开着clash的,加条分流规则 IP-ASN,13335,xxxxx (xxxxx是邻国的节点,ping值10ms。感谢chatgpt,让我知道可以ASN),瞬间世界重新恢复了美好。
root@OpenWrt:~# ping 1.1.1.1
PING 1.1.1.1 (1.1.1.1): 56 data bytes
64 bytes from 1.1.1.1: seq=0 ttl=54 time=112.493 ms
64 bytes from 1.1.1.1: seq=1 ttl=54 time=114.242 ms
64 bytes from 1.1.1.1: seq=2 ttl=54 time=113.530 ms
root@OpenWrt:~# traceroute 1.1.1.1
traceroute to 1.1.1.1 (1.1.1.1), 30 hops max, 46 byte packets
1 x.x.x.x (x.x.x.x) 2.521 ms 1.529 ms 5.002 ms
2 10.55.49.45 (10.55.49.45) 4.486 ms 10.55.49.47 (10.55.49.47) 2.787 ms 10.55.49.45 (10.55.49.45) 4.572 ms
3 10.55.37.86 (10.55.37.86) 6.924 ms 10.55.37.90 (10.55.37.90) 3.662 ms 10.55.37.86 (10.55.37.86) 5.241 ms
4 * * x.x.x.x (x.x.x.x) 61.770 ms 俺们村的IP
5 one.one.one.one (1.1.1.1) 112.578 ms 113.631 ms 112.346 ms
/cdn-cgi/trace显示是俺们乡的node
前几天才把代码再次分享出来,今天就可以用上了,甚是欣慰。
不过,别人用这脚本买到的机器比我自己买到的还好。唉,我就是这么手气背。
源代码如下,go的:
https://blog.lostshit.com/index.php/archives/325/#comment-245
ks-le-b参数是:
required_plan_code: "26skleb01-v1"
options:
- "bandwidth-500-26skle"
- "ram-32g-ecc-2400-26skleb01-v1"
- "softraid-2x450nvme-26skleb01-v1"
不过已经断货了,当然,挂挂机也许可以买到别人退货的。不要中奖的话其实也可以了,性价比拉满的。