WeWork 提供的 Wi-Fi 不支持 IPv6……😒

https://mp.weixin.qq.com/s/-5BQM2S0_AoxdeIHlpoqnA

支持下俺写的文章吧🥰感谢 Dify 和顺丰 AI 技术平台组的小伙伴们

https://fixupx.com/yossense/status/1995177947393884412

パフォーマンスの最中に突然首を締められ、まるで物みたいに横へ突き飛ばされる——
この行為のどこが「面白い」んだ？

こうした無作法を批判すると、
「日本のお笑い文化を否定してる！」とか曲解してくる奴らがいるけど、
逆に聞くけど。これのどこが“笑いどころ”なんだ？ 説明してみろ。

他人の生命を脅かす行為なのは言うまでもないが、
自分の娘が全国民の前で同じことをされても、
それでも笑っていられるのか。

それに、高市総理大臣が「働いて働いて働いて働いて働いてまいります」と掲げてるこのご時世に、
他人の仕事を妨害するだけの“茶番”を堂々と流すって、どういう神経だよ？

あの無礼者も、BPOも、そしてあの男を擁護してる連中も、
まとめて高市さんへの公然たる蔑視にしか見えん。
非国民だね、これはｗ

FixupX

ヨス Yosuke Yano (@yossense)

日本のバラエティの気持ち悪いとこが詰まってる

・成人女性が子どものような格好をさせられて個性を殺された操り人形のように振る舞う

・コメディアンが「笑い」のために女性や立場の低い男性に乱暴する、雑に扱う

・それを見て周りが笑う

・ダメなことだと思っても空気を読んで笑ってすませる

Quoting capsulebunny (@capsulebutt)

Maybe the only big culture shock I’ve ever got here was at my first job and…

这些媒体，这些大V，在网上多重复几遍，不管真假，都会在人脑子里留下印象。时间一长，谁还记得这么多细节。只能记得个大概：滨崎步一个人的演唱会不实。

🔗 历史押韵｜滨崎步“一个人的演唱会”信息不实吗？这个辟谣角度很刁钻

小薄荷还是七斤的样子

Photo

去朋友家撸猫了，收获很大！（主要指通过丰富的实践 其实就两次 记住了七步洗手法的口诀：

内外叉勾大立腕

仿佛重新回到了读大学的时候……🥹

其实小薄荷没有这么调皮，它咬也不是真的在咬，要么是跟我玩要么是在告诉我手法不对（养猫人最严厉的父亲
很亲人很喜欢梳毛的小猫咪，但是从来没养过猫的我在梳毛的时候手法太笨拙了，所以被“狠狠”教育了几次
临走的时候诱导主人给它剪指甲，捏住了它命运的后脖颈，报复回来了嘿嘿嘿……

https://fixupx.com/charliermarsh/status/1995497948768264414

最喜欢和最想掌握的一种测试开发规范

🧵 Thread • FixupX

Charlie Marsh (@charliermarsh)

The ty test suite is "written" in Markdown. Every code block here gets evaluated, with the comments representing expectations.

We have almost 300 of these files that effectively read as detailed documentation for how ty behaves and how the Python typing…

https://fxtwitter.com/vspo3594/status/1995407339630030986

很明显没有违反交通规则却被警察（日本没有交警）叫下来罚款...
除了需要创收想不出别的动机

FxTwitter

0:23

PAPAN (@vspo3594)

みんなもドラレコ付けようね

Quoting PAPAN (@vspo3594)

青信号の交差点で右折待ちしてたら警察官に止められて信号無視に仕立てあげられかけて草
ドラレコあって良かったァ

朋友问我为什么感觉 AI 一点都不提效，仔细一问，原来他在用 qwen coder

我觉得不管他说的话是想当然还是想当初，就当作是自己上当受骗，也可以试着按照他的建议浪费 7-8 年的人生在北京
就算最后没有能够留京，至少至少——北京真的是一座能提升幸福感的城市
因为只要你待过北京，你去国内其他任何城市都会觉得很幸福

Lance Yang 老师昨晚在评论区为我指明方向，我觉得这个很重要所以整理了一下单独发出来，因为这个问题在互联网上似乎搜不到正确的信息，AI 也全军覆没。

envoy sidecar 在云原神里被用做透明代理，pod -> remote 的流量（几乎）被全量劫持到同一 netns 里的 envoy，实际路径是 pod -> envoy -> reomte （正向代理，两个 tcp 会话）。不过 envoy sidecar 劫持流量默认不使用炫酷的 tproxy，而是古典的 REDIRECT

iptables -t nat -A OUTPUT -j REDIRECT --to-ports 15001

把 packets DNAT 成 127.0.0.1:15001。
envoy 劫持到这个流量之后，通过 getsockopt(SO_ORIGINAL_DST) 拿到原始的 dip:dport。
回程的 rev-DNAT 由 nf conntrack 隐式处理。

这看起来没有问题，但是注意力稍微集中一点就能意识到 DNAT 之后可以导致连接冲突。我们可以显式地尝试构造这种冲突：

import socket, sys, time
sk = socket.socket()
sk.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
sk.bind(('', 19233))
sk.connect((sys.argv[1], int(sys.argv[2])))
time.sleep(1000)

先运行 python main.py 1.1.1.1:80 建立一个 nodeip:19233 -> 1.1.1.1:80，然后再运行 python main.py 1.0.0.1:80 建立一个 nodeip:19233 -> 1.0.0.1:80。两个 tcp 连接有不同的 dip，零冲突，很合规。
但是 iptables DNAT 之后，两个连接都变成了 nodeip:19233 -> 127.0.0.1:15001，这样后发起握手的连接似乎必被 reset，就算安慰自己“这应该是小概率事件”，严肃的工程师都应该意识到这绝对会让生产爆炸。

但是真的如此吗？

立刻着手测试，发现第二个 tcp 其实也能成功握手，ss 看到第二个连接的 sport 居然被 SNAT 了，这就是昨晚 Lance Yang 的发现：

nf_nat_redirect_ipv4
-> nf_nat_redirect
-> nf_nat_setup_info
-> get_unique_tuple
-> nf_nat_l4proto_unique_tuple
-> nf_nat_used_tuple_harder

有趣。最新代码，NAT REDIRECT 如果源端口检测到冲突后会自动进行源端口重分配 。。。

用 pwru 追一下 skb，会发现还要稍微复杂一点点，以下是 pwru --all-kmods --filter-track-skb 'tcp[tcpflags]=tcp-syn and src port 19233' 的导演剪辑版：

10.0.0.16:19233->1.0.0.1:80     ip_local_out
10.0.0.16:19233->1.0.0.1:80     __ip_local_out
10.0.0.16:19233->1.0.0.1:80     nf_hook_slow

// iptables -A OUTPUT -t nat -j REDIRECT

10.0.0.16:19233->1.0.0.1:80     nft_nat_do_chain[nft_chain_nat]
10.0.0.16:19233->1.0.0.1:80     redirect_tg4[xt_REDIRECT]

// DNAT, be aware of changes of dport and dip, and re-route

10.0.0.16:19233->1.0.0.1:80         l4proto_manip_pkt[nf_nat]
10.0.0.16:19233->1.0.0.1:15001      nf_csum_update[nf_nat]
10.0.0.16:19233->1.0.0.1:15001      inet_proto_csum_replace4
10.0.0.16:19233->1.0.0.1:15001      inet_proto_csum_replace4
10.0.0.16:19233->127.0.0.1:15001    ip_route_me_harder

// iptables POSTROUTING

10.0.0.16:19233->127.0.0.1:15001 apparmor_ip_postroute

// extra SNAT due to conflicts, be aware of the change of sport

10.0.0.16:19233->127.0.0.1:15001    l4proto_manip_pkt[nf_nat]
10.0.0.16:46801->127.0.0.1:15001    nf_csum_update[nf_nat]

额外的 SNAT 并非发生在 -j REDIRECT 的 OUTPUT nat 里，而推迟到了 POSTROUTING nat，通过 ct 来传递 SNAT 信息。nf_nat_redirect_ipv4 只会计算出需要 SNAT 的新端口，记录到 ct 里，待到 POSTROUTING 再 SNAT。
如果此时再加入一些 SNAT --to-source 会怎样，其实也不会怎样，ct 只有一条干净的 entry 记录 10.0.0.16:19233 -> 1.0.0.1:80 被 NAT 成 127.0.0.1:13902 -> 127.0.0.1:15001，所有 ip port 都被换过。

这对 envoy 用户态调用 getsockopt(SO_ORIGINAL_DST) 没有影响，rev-NAT 也无需用户态操心，延迟 SNAT 的行为目测半完全正确（否则在 OUTPUT 发生隐式 SNAT 、影响 POSTROUTING 的规则命中就绝了😊），就算 POSTROUTING 再次命中显式 SNAT 也没关系，几乎不会踩坑（除了要消耗 ct），唯一需要注意的就是在旁路观测的时候不能通过 socket tuple 来配对 client socket 和被劫持的 conn socket😭因为我真的就在这么干，周一改。