@zhzbql 同时起了多个进程

我可能搞错了，524600 字节并不大。再抓一晚上数据看看。

@alvinbone88 厉害啊，应该就是这个问题了。屏蔽 microsoft.com 后客户反馈 ok 了。但是长久来看，还是应该解除这样的访问屏蔽，让系统可以更新到根证书。

@starsky007 我也是在试。因为卡住的时候，tcpdump 正好都能在网关上抓到附言中提到的 IP 访问，并且那家公司貌似在防火墙上限制了它的访问，于是开始怀疑这几个 IP 了。通过 IP 反查，看出来应该是微软的 CDN 地址，结合公司内网的 DNS 查询记录，大体确认是访问几个 microsoft.com 后缀地址。于是干脆先在 DNS 服务器上加了一些规则，把 microsoft.com 后缀的 dns 查询直接返回 127.0.0.1 。先这样跑着，看看客户的反馈。

@misaka19000 用 tcpdump 貌似发现了一点规律

@jatsz 嗯，其实很难复现。用 curl -v 很快

@misaka19000 嗯，正抓着呢，希望能发现点什么。

@starsky007 它也会出现偶尔 12s 的握手时间

@hronro 你说的对。不过一旦所有节点和 lighting house 建立了连接，那 lighting house 就可以和所有节点通信。如果我们再配置上 unsafe route，那就变成 lighting house 可以和所有节点后面的子网进行通信。这个时候，我们就可以把 lighting house 当成一个路由器用了，配置一些 iptable nat 规则，就可以对每个节点后面的子网相互转发数据。

@hronro 老帖子了。确实，udp2raw 只能解决 lighting houre 和其他节点的通讯问题。其他节点之间的通讯，全靠 lighting
house 转发:doge:

@Suclogger prometheus+grafana 跑通，相当不错的工具。

@ajaxfunction 在同一个子网内，树莓派 A 发起向树莓派 B 的请求之后，内部会做一次 ARP，将目的 IP 地址转换成 MAC 地址，然后再发出数据包。

交换机收到数据包之后，查询数据包二层帧就能找到目的 MAC 地址所对应的端口，就会将数据直接发送给树莓派 B，而不是再往上传递给网关。

@bboymega @szqhades 我记忆中，貌似如果是同一网段的局域网设备，不需要网关 /路由器就可以通讯。是不是这些数据其实都不经过网关的。

@Microseft 是二层交换机结构。一共分布在三层楼，每层一个大交换机，然后大交换机层叠到另一台大交换机。现在的情况是，即使在同一层的设备，速度也上不来。

@Suclogger 4 代树莓派，我在测试环境跑到几百兆问题不大。prometheus+grafana 我试下

升级到最新版，错误消失

单臂路由。https://www.v2ex.com/t/453362

@wd 感谢，确实是这样，大概等了两分钟文件变化了。

@wd 嗯，是的，会生成一个 secret，mount 成 pod 中的一个文件。我的 go 程序会检测这个文件是否变化（通过 certman ）来决定是否重新读取。但是似乎没有生效。但是重新启动 pod 会生效。