@chengxiao #10 snap 就相当于官方版的一键脚本，这东西是给工作中需要操作 linux 服务器的运维和开发人员设计的，而不是给 linux 用户用的，linux 用户自然不喜欢这东西。

如果你是 linux 用户，那么使用你使用的 linux 发行版。
如果你不是 linux 用户，只是工作需要操作运行 linux 系统的服务器的运维或开发人员，那么 ubuntu 是最适合这类人的。ubuntu 整的 snap 之类的虽然没人愿意用，但是专门给这类人设计的。

OP 有用过 gnome 吗？ gnome 的 HIG(human interface guideline)对触屏、手势和键盘非常友好，应该更适合盲人用户使用。
之前在 hn 刷到帖子，他们本身就很重视 accessibility ，有专门的 funding 和盲人工程师。

js 生态可不原始，一直都是最具活力的生态。
python 现在现代的工具链就 rye 吧 https://rye-up.com/
相当于 rustup for python 。

到底谁教的用 docker 跑 openwrt ，这不是支持的使用场景。你要真的不想跑 VM ，至少用个 firecracker ，也比容器好。

@auv1107 你只需要回答：假如你确实想要偷偷上传数据，你有能力做到吗？用户使用你开发的这个工具之后，你仍然能做到吗？
如果这两个问题的答案是 true ，那么结束，观众应该都能理解什么是虚假的安全感了。

这个确实可以理解，Google 在隐私方面的名声可以说是臭名昭著，对 vpn 业务来说 google 这个品牌就是最大的负资产。

@lanlanye 你别说，因为 Google 一直弹 recaptcha 忍不了换到 DuckDuckGo ，发现 ddg 的搜索结果质量无论中文还是英文都足以替代 Google ，并且 ratelimit 非常宽松，无论 ip 多烂都能正常使用，对于使用共享 ip 的用户确实建议用 ddg 替代 google.

@auv1107 你在主贴提出的“用户担心剪贴板管理器上传数据”和你在本帖发布的这个应用（想要）解决的“其他应用未授权访问剪贴板”是两个完全无关的问题。
> 做这个开源的是因为有些人不信任闭源的剪贴板管理器
> Q：「如何在保护用户数据的同时，也让用户放心?」
> A：「现在,我有了一个初步的解决方案: 发布一款开源软件，防止系统剪贴板被滥用。」
你发布的这个解决方案并不能解决用户担心的问题，所以只提供了虚假的安全感。

如何把系统设计的你不能够访问用户数据、且能够证明你不能够访问，是你的问题。但似乎你并不了解也不想了解相关的技术。你的长篇大论一句话总结: trust me, bro.

@raptor #14 你这就想当然了，给你冲花费的来源也可能是一个为了能访问 v 站的普通 v 站用户。

@auv1107 #14 所以这个产品的目的是为了提供虚假的安全感，让本来不信任你的用户信任你，而不是消除信任你的需要(aka zero trust)。
> 为何我该相信你不会秘密上传数据？
这个问题有且只有一个答案：证明你不能。

安装发现 greasyfork 是打包以后的 artifact ，去 git 仓库里也没有找到源码，仓库里提交的也是打包以后的 artifact ，
https://github.com/zyronon/web-scripts/blob/master/V2Next.user.js

如果不打算公开源码，建议显式告知用户，并更改 license 不要用 GPLv3 。（使用任何 license 是你的自由，没有要求你公开源码的意思）

@eh5 你认为 nat64 是限制性应用场景，我解释 xlat 能兼容所有 nat44 的场景;你认为 nat64 对家庭用户比双栈网络没有连通性和速度方面的提升，我告诉你事实上是有，很多用户双栈网络的连通性和速度还不如 ipv4 only ，他们关于禁用 ipv6 的帖子搜索引擎一搜一大把。对了，作为一个 side effect ，nat64 还能让你不用为了实现 hairpin 而把所有内网入站连接都从外部网卡绕一圈，你认为这种做法没问题那就没问题吧，记得告诉你的用户在防火墙中允许来自公网接口的入站连接以及相应的 security implication 。

当然你认为以上都是 off topic ，“没有看到你的侧重点单方面输出”，没有问题，是否实现或以什么优先级实现 nat64 是你的自由，我并没有要求你做什么，其他问题跟用户说去吧，本帖不用再回复。

@eh5 说道性能，还有一个值得考虑的问题。现在常用的家用嵌入式路由器的 cpu 根本无法支持高带宽场景下的 nat ，而是 offload 到专用硬件处理。考虑到这种硬件应该是负责重写包而不是负责连接追踪，实现支持 hw offload 的 fullcone nat 应该是可能的，只不过能否通过 ebpf 就不知道了。不然的话，很可能受限于嵌入式设备的性能而让用户的带宽严重降低。

@eh5 你说的对，内部网络之间（非同一子网）的 p2p 应用确实需要最外层的 nat 网关支持 hairpin ，这是我之前忽略了的情况。但 nat 就是这样的 hack ，开启了 hairpin 会 break 某些应用，关闭了 hairpin 会 break 另一些应用。是否需要 hairpin 取决于具体需求，比如现在大部分家庭用户都是无公网 ipv4 （意味着 hairpin 发生在最外层的运营商 cgnat 上）+公网 ipv6 （对任何 sane 的 p2p 应用都是首选），实现 hairpin 的意义就不是那么大。
hairpin 最大的问题是 snat ，snat 会丢失源地址信息，当你收到一个入站包的时候，你必须 remotely 知道你要转发的目的主机到源主机之间的路由是否还经过你，才能决定是否进行 snat ，这很难正确的实现，你只能假定一些简单的网络拓扑下的情况。
具体到通过策略路由把目的为本机的包强行发到外部接口上，这已经 break 了其他所有人预期的行为，而你无法提前知道和测试所有的使用场景。比如本机端口冲突、多实例多地址个外部接口和类型（ eth/pppoe/wireguard/其他基于 tun 的代理程序）的动态路由场景，动态 ipv4/ipv6 地址。并且这会让所有目的的为该地址的入站包全部发送到外部网卡再转发回来，那么本来从内网入站的包源网卡成了外部网卡（并且经过两遍 netfilter ），正常系统都会默认的允许内网入站、禁止外网入站的防火墙规则也就 break 了。更不用说如果内网接口都是 virtio 的虚拟网卡，这种转发会非常严重的降低性能（这还没有考虑 ebpf 本身的开销，在嵌入式设备上应该也是不可忽略的）。
我觉得既然因为网卡上的 ebpf 无法捕获发往本机的包，那干脆直接让用户态的服务 reserve 所有活跃记录中的端口，然后对 hairpin 的请求直接在用户态转发，这样也能解决端口冲突问题（其他程序没有办法得知 nat 使用了哪些端口）。

NAT64 并不是限制性应用场景，646xlat 不同于 nat64 ，它是无状态的静态重写。对于支持 464xlat 的终端，并不会 break 任何除了 nat44 已经 break 的应用，唯一的 regression 就是网关有没有实现 fullcone 。当我说所有现代设备，我指的是所有面向消费者的设备，所有可以插 sim 卡的系统都必须实现 464xlat （因为很多运营商的移动数据已经是纯 ipv6 了），包括 windows/android/ios ，linux 没有把它做到开箱即用确实 behind 了。对于不支持的设备，它们不太可能依赖内嵌 ipv4 的应用，这些设备要么压根根本不需要公网联通，要么可以在纯 ipv6 环境工作。
如果你考虑连通性方面的好处，那么毫无疑问增加 ipv6 的 adoption 是对每一个 p2p 用户都有好处的。ipv6 现在的状态已经达到了只要你是接入 isp 的就已经普及了，没有的都是本地网络不支持（云厂商/企业/家庭网络用户自己），去搜一下会发现用户自己禁用 ipv6 的原因，像什么卡/打不开网页禁用 ipv6 就好了，都是因为复杂度或某些系统实现的问题（没错，又是 android ），而这些问题在纯 ipv6 环境下却可以解决和避免。如果以后因为缺少一个 fullcone 的 nat64 实现（上游那些生活在公网 ip 非常充裕的国家的人不太可能去支持）而 block ipv6 的 adoption 的话，对 p2p 应用绝对是不好的，用户希望能够同时拥有 ipv4 fullcone 和 ipv6 gua 的连通性。从端到端连通性的角度来看，fullcone 的 nat64 比 nat44 更 canonical ，毕竟打洞总是 hack ，ipv6 才是“正确”。

不过实现 nat64 确实会引入额外的复杂度，虽然在 nat44 的基础上没有额外的状态只需要一些静态重写，不熟悉 ebpf ，但是现在只有重写地址就要两千行了（可能大部分是维护状态？），再加上构造包可能会不容易，我记得几年前还看到有新闻把 rust 编译到 ebpf ，现在也没发展了。
上面回复有提到需要构造 icmp 报文返回 mtu 问题，这应该搞错了吧，分片或者返回 icmp 应该是网络栈或者网卡的事，nat 只是重写包的地址，甚至是否 EIF 都是防火墙配置的，和 nat 有啥关系。

@eh5 #19 如果我理解的不错的话，把这个 ebpf 挂载到网卡上之后，对网络栈的其他部分而言完全透明，就好像根本没有使用 nat ，来自的内网地址的包会被公网的路由器发回来一样。
这样的话 netfilter/策略路由行为应该和分配到一个公网 ipv4 网段的路由器一样，你自己维护自己的映射表，和内核的 conntrack 也互不影响，多个外部网卡运行多个实例进行策略路由的情况下应该也不会有问题。
不过这个 harpin 看起来有点太 hacky ，这样做肯定会和很多东西冲突的，比如本地监听的程序和 netfilter dnat 。对于 masquarade 而言根本不需要做这种事情，没有哪个 p2p 的应用需要从内网访问映射的端口而不是直接连接。这种事情就交给 netfilter dnat 做，只要端口不冲突应该就不会冲突，hairpin 需要进行 snat ，会让应用丢失掉源地址信息，只有特别需要的场景才会专门配置 snat ，或者在用户态使用 proxy protocol 的转发来保留源地址信息。

关于 nat64 ，最主要是能够控制 android 这种不允许用户控制、且 ipv6 实现不完整的设备在双栈环境下的行为。
纯 ipv6 网络就不要部署以 ipv4 地址作为 host 的 http 服务啊，可以用 hostname （ dns/dhcp 自动分配和解析），或者配置一个简单好输入的 ULA 地址，实在不行可以手动为需要的设备配置静态 ipv4 地址（甚至 dhcp 也行），但是不要下发路由和网关，这样依然是一个纯 ipv6 网络。访问外部的 ipv4 http 服务也不需要专门配置，现代系统会自己自动进行本地 464XLAT ，虽然多了层套娃，但这种转换对网络侧透明，不会增加复杂度。
还有一个 nat64 与打洞相关的场景，一个 p2p 应用可以监听一个 GUA ipv6 的 socket ，然后同时接收来自打洞映射的 ipv4 入站和 GUA ipv6 入站，也就是纯 ipv6 下的 p2p 应用可以无缝的、透明的和纯 ipv4 下的 p2p 应用互联。无论 ipv4 的打洞是否成功，该应用都可以接收到入站，并且在不同的网络环境不需要单独处理或配置双栈。

@eh5 #2 常见的家庭使用场景：
通过策略路由把在 netfilter 中根据元数据打了不同标记的包路由到不同的外部接口。
通过 ct 把来自外部接口发起的入站连接打标把相应的回复包从它们的来源接口发回去。
通过 ct 把来自某个 mac 地址的包打标从而能够在路由选择之前匹配到将要发送到该地址的包。

通过 nat64 能部署纯 ipv6 内网最大的好处就是简化双栈网络的复杂度，防火墙/路由/地址规则不用每个主机都重复两遍，双栈选择可以直接在 dns64 服务器中配置，不用为每个应用每个设备都单独配置，用容器跑个 p2p 应用不用修改镜像的 gai.conf （非 glibc 的应用也不一定遵守），有些系统（如 android ）直接硬编码 prefer ipv6 无法修改。
常见的 dnsmasq/adguardhome/pi-hole/dnscrypt-proxy 等转发器都内置了 dns64 的功能，不过国内的公共 dns 没一个支持 dns64 的。

这个看起来不错，但是不知道在和 netfilter/contrack/策略路由一起使用的时候会不会有未预期的行为，导致流量泄漏等问题。
其实开一个用户态的实现了 fullcone 的 socks 代理，就可以满足很多应用的需求了。
有状态的 nat6 应该是没什么使用场景的，ipv6 一般不用 nat ，即使需要 NPTv6 几乎总是最好的选项，除非你只有单个地址并且上游也是 fullcone 的。
相比之下不如整一下 nat64 ，尝试把内网完全迁移到 ipv6 only ，可以极大的简化维护成本和 p2p 连通性问题。
所有层 nat 全部都是 fullcone 的话，确实可以无限套娃，stun 打洞也能正常工作。但 upnp 那一套主动打洞协议却没有办法自动转发请求给上游，通过 stun 自己实现其中一部分协议应该是可行的。

@kyoutarou #77 只要 pcdn 和 pt 用户永远不能理解公平使用原则，自己幻想合同里没写的 7x24 跑满标称宽带是允许的，那么这种一刀切就必然会发生，自然是普通用户买单。
运营商其实真的不想限制你的用量，你用的多厂商付钱就多，更符合他们的利益。