你要抓还是要改，只是抓的话基于 ebpf uprobe 的方案可以无视 ssl pinning
https://github.com/gojue/ecapture

debian/ubuntu 是常规选择，ubuntu 主要是技术选型更加现代（例如使用了 networkmanager 而不是 ifupdown ），但我觉得 deb 系它们的仓库里面东西感觉有点太少了，ubuntu 上你想装个 kubectl 它居然叫你去用 snap ，过于抽象
非常规选择的话，主要考虑 immutable os ，方便维护和规模化部署，常见的就是 fedora coreos 和 opensuse microos
但是它们没有解决在大量节点间进行系统环境更新的困难，我自己 Homelab 是跑的 NixOS ，更适合大规模的进行同步部署，但非 FHS 环境造成的问题导致它学习成本过高

我试了一下，问“穿背带裤，有数亿粉丝的，中国的“篮球巨星”是谁？”它真的会自动用 4o-mini
但是问一些复杂的问题它自动是 4o

@geekvcn 树莓派智商税...? 那些国产派甚至大部分不能用主线 mesa, 小部分甚至只能用神秘来源 mesa 的二进制, 而且大部分 vulkan 1.2 都支持不全, GPU 根本不能用
而且甚至还有很多用不了主线内核

AdguardHome 的全部功能就是一个 DNS 转发器+DNS Filter+前端，刨除前端部分，dnsmasq 都能实现过滤，而 mosdns/knot-resolver 则健壮的多
此外旁路由...非对称路由警告, 入站流量不能 Conntrack 警告

存储或交换密钥，比如说 matrix 就支持通过扫描二维码来传递端到端加密的 session key
还可以支持线下扫二维码来 verify 线上交换的密钥的真实性或者离线交换端到端加密的密钥

了解了以下，支持 switchdev 的话确实 vf 或者多个 pf （包括拆分后的）可以直接通过 linux bridge 片上交换
这么看 e810 确实是可行的，但是还是推荐 mellanox
楼主节点多的话建议整个交换机吧，少折磨自己（

说实话不太有，而且多 function/virtual function 片上交换是的 bridge 就可以实现 offload 的吗？
得用 openvswitch 和 openflow + switchdev 吧，你先确定能用上再说

v6 可以保证所有设备都具有公网 IP ，这对于实现零信任+零配置的完全点对点通信意义重大

如果要给 linux 平台开发 electron 软件，请务必考虑一下在 wayland 下的输入法问题，即便现在 xorg 还能用，但 wayland 也是趋势
而 wayland 下 electron 仅支持 text-input-v1 ，目前大部分 compositor 没有且不打算支持（但未来可能会更好，比如说 mutter 现在已经有了相关 pr ）
现状可以参考： https://www.csslayer.info/wordpress/fcitx-dev/chrome-state-of-input-method-on-wayland/
而 Tarui 则完全没有 chromium 所带来的问题

如果连一个不开 PMF 的开启 802.11k/v/r 的 WPA2-PSK 的 2.4/5Ghz 混合 SSID 都连不了 IoT 设备，那我觉得真的可以退了，折磨自己，虽然你的确可以单独开一个 SSID ，但考虑到 IoT 设备一般会有二层互联的需求，这等同于降低整个网络的安全性

@ChaosAttractor 修正 此外 FRP 等一般用于单一的静态 **端口** 的穿透（转发），而作为 Default Route 则需要能被三层路由原始流量的能力

这些都是 Linux 的容器化技术，内核层面依赖 CGourps 实现，它可以提供在同一个内核中隔离多个用户空间进程，你可以理解为 LXC 里面的进程和外面的进程性能什么都是一样的（当然也可以限制），只是所有东西互相隔离
共享内核意味着 0 额外性能和内存开销，只有里面的进程会占用内存
而 LXC 则是管理管理 CGroups 和各种 Namespace 隔离的用户空间程序，类似的还有 ContainerD 和 LXD ，Docker 和 K8S 则基于 ContainerD
此外它们支持嵌套，所以在 LXC 中运行 Docker 并无不妥，因为 LXC 一般直接用于替代 Hypervisor
但 LXC 的网络基于内核的 NetNS ，并且因为共享内核和非特权的设计使得 eBPF 和 iptables/nftables 功能受限，而且大概率你还需要 CPU 转发（虚拟化则你可以直通网卡），各种硬件卸载功能也受限（当然如果你在用最新最热的 Mellanox 网卡那支持的还蛮好的）
一般作为路由我觉得不太合适

推荐静态场景用 Tailscale 或 Wireguard 等进行组网（当然也可以 SD-WAN ）而不是用内网穿透服务，尤其是你还有公网 IP 这种条件
此外 FRP 等一般用于静态 IP 的穿透，而作为网关是需要能被三层路由的，FRP 什么的可能做不到
如果你只是需要异地组网，通过 wg 或者 tailscale 打隧道运营商是没有理由管的，不过可以被嗅探到是 vpn （ wireguard 有明文包头）
此外就算要对外提供访问也只需要在有公网 IP 的路由上设置端口转发就可以了

这个需要 BIOS 来实现吧，很多机器可以用逆向工程得到的 ACPI CALL 来控制（比如说华硕有 asusd ）
如果机器不支持就没戏？

你之前 ping 网关时候网关的地址都是典型的 SLAAC 地址，你确定是只能用 DHCPv6 而不是只能有 SLAAC?

你这个网络环境是不能通过 dhcp-pd 等方法拿到 ipv6 段吗？（一般就是校园网，光猫无论桥接与否一般都可以 dhcp-pd ） tplink 这个桥接模式应该是 slaac-relay ，也就是中续并篡改 RA/RS 包的 mac 地址，然后配合 NDP-Proxy ，网关做三层转发（也有不用 NDP-Proxy 纯二层的实现，参考 https://blog.men.ci/ipv6-slaac-relay-and-bridge ），这是一种没有办法的情况下（需要鉴权且只允许有一个 mac 地址联网）才会使用的很窒息很 hack 的模式

如果可以接受 NAT 的话，可以找找路由器有没有 ULA+NAT66/NTPv6 的选项

这种模式下应该只能使用 SLAAC ，DHCPv6 的话需要额外实现 DHCPv6 报文的中续和篡改（具体实现方法取决与你的 NDP-Proxy 的实现会不尽相同）

但是很显然你用了 DHCPv6 （显然你的地址不是 eui64 生成的），以及你拿到的地址也有些奇怪，很少见到 ::d:dddd 这种风格的地址，大概率不是你的路由器给的，是上游的网关给的，你可以用 ip -6 route 来查看一下 Default Route 是什么地址，看看是不是你的路由器

你的路由表里关于二层的路由应该没什么问题，但是 Default Route （网关）大概不是你的路由器而是上游的网关，那么就要看你路由器的 NDP-Proxy 是怎么实现的了，如果它的中续是双向的，那么你就可以联网，否则你可以理解为是你的路由器的实现有问题

此外你说 Windows 可以联网，Windows 是通过 DHCPv6 联网的？？你试试看安卓能不能联网，安卓只支持 SLAAC