如果光猫是路由模式，说明光猫的直接下级获取公网 IP 没问题。即使没有下发前缀，路由设成 Passthrough ，路由的下级设备通常也能获得公网 IPv6 。
IPv6 的端口映射、DDNS 和防火墙详细配置是比 Passthrough 更进阶的功能。如果路由不支持 Passthrough ，那这几个大概率也没有原生支持。

有点好奇买专线上境外网站就一定合规么，看到有的合同会写“不得将跨境云专线与互联网相连接”

除非足够方便，可以成为默认的习惯

问是否裁员，答还在招人

@Masoud2023 现行 v4 NAT 就是实名的，v6 还能怎么更实名。一对一绑定前缀那路由表乱套了，一对一绑定后缀那企业会把用户隐私玩坏。

估计只有让不支持 v6 的网络难受才能推得动

@Tyuans 这个通知说的是网络去 NAT ，IPv4 私网地址加快退出。有的地方干的恰恰相反。

@doruison 误杀是指被误以为是梯而干掉。单纯数据不在境内流量又大被封是不是应有之义，外界不知道，能知道的只是有许多现存健在的案例。

@LnTrx 毕竟，现有艺术作品的历史，也有很多是有疑问的。至于艺术性的赏析，那更是仁者见仁。

一个思维实验：
用 AI 创作一幅抽象画，再用 AI 编一段故事背景和艺术分析。如果 AIGC 继续发展，肯定有一天会编得让人难以发现破绽。这时，对于被骗到的人来说，知道真相前和知道真相后，其价值有什么区别？

@ungrown 其实这几个还算正常
境外节点：国外 APP 很正常
无名小站：很多知名服务背后提供服务的域名也很怪
莫名其妙的主页：提供服务的域名没有主页都很正常
多到吓人的加密流量：毕竟 https 等已经很普及了

如果真按这个标准作为特征，误杀率想必居高不下

只增加下行，500M 升 1000M 没啥意思，除非有很明确的场景

@az22c 如果服务直接部署在 B ，就没必要再研究 B 、C 的互访，同时避免 C 局域网暴露造成的额外风险。担心 B 沦陷连累局域网的话可以在网关做额外限制，更重要的是加固其他设备的局域网暴露端口。（既然考虑 B 沦陷，那 B 自身防火墙禁止访问内网似乎意义有限）
另外的方案就是直接在 C 上运行虚拟机。比上述方案增加了逃逸的风险，当然民用很难碰到 0day 的逃逸攻击。但方便的点在于不用维护一台额外的设备，可以通过共享文件访问特定目录，同时控制虚拟机网络比较方便。可以在虚拟网络与宿主机通信（配完可以验证一下哪些宿主端口可访问），避免宿主机向真实的局域网暴露端口。
当然以上都是基于远程桌面的方案，如果是我自己还是更倾向于转发 https 。

写了半天注意到你怕的好像是勒索病毒，那把重要资料定期异机备份可能是更需要的保护。

@az22c 我考虑得可能还不够周全。
另外想问下，你增加一个跳板，目的是为了保护笔记，还是宿主机。如果只是保护宿主机，那直接在 B 部署笔记不就完了。如果远程桌面方案想额外保护笔记，那还需要好的使用习惯。比如在 B 的浏览器里保存了密码，或者登陆了没退出，此时远程桌面被攻破，不也一样白搭。相比其它远程桌面方案，物理隔离对笔记的保护没有增加多少。

@LnTrx 如果这都要考虑，那 A 上应用更可能有漏洞，导致 B 也可以攻击到 A 。
修正> 如果虚拟机逃逸都要考虑，那 C 暴露在局域网的服务出漏洞更要考虑。这样的话，B 自然也可以攻击到 C 。

@az22c 如果这都要考虑，那 A 上应用更可能有漏洞，导致 B 也可以攻击到 A 。
对比一下：

1. C 直接部署笔记服务，https 暴露外网
如果笔记服务有重大漏洞（比如登录界面可以访问到主机文件），会威胁整台机器

2. C 直接部署笔记服务，https 暴露外网，nginx 额外加一层密码
即使有重大漏洞，外界绕不过外层密码也难办（但有些 App 可能会不兼容额外的访问控制）

3. C 使用虚拟化部署笔记服务，https 暴露外网
如果笔记服务被攻破，虚拟环境可访问的信息会沦陷。
宿主的风险取决于虚拟化技术。对于虚拟机，逃逸是价值很高的漏洞，对于民用场景不太会遇到。Docker 可能需要加固。

4. C 直接部署远程桌面访问仅限本机的笔记服务，远程桌面暴露外网
如果远程桌面有重大漏洞，那会威胁整台机器。如果套一层隧道，那进一步取决于隧道协议和虚拟局域网的安全性。

5. B 部署远程桌面访问 C 仅限局域网的笔记服务，远程桌面暴露外网
首先取决于远程桌面的安全性。如果被攻陷，且局域网内有不设防 /高危漏洞的服务，可能会让运行该服务的机器进一步沦陷（除非额外限制）。B 本身的使用痕迹也可能成为跳板（比如保存了密码）。另外，局域网内其它设备也可能威胁笔记服务（除非额外限制）。

6. C 部署虚拟机运行远程桌面通过共享访问笔记，远程桌面暴露外网
如果远程桌面被攻破，虚拟环境可访问的信息会沦陷。是否能访问局域网其他设备取决于虚拟机网络的配置。
如果虚拟机存在逃逸等漏洞，会威胁到宿主机。

综合看下来，其实就是估计笔记服务出漏洞、远程桌面被攻破、虚拟机发生逃逸、隧道被攻破的可能性（同时考虑 ABC 自身以及虚拟局域网中其他设备等风险），组合出安全系数满足需求、同时不至于太麻烦的方案。个人认为民用场景下，虚拟机的隔离已经够安全了，实在不行加一层密码 /隧道。过于复杂的方案比较难以坚持，而且可能会增加新的风险点。

@wy315700 准确地说是健康度指标掉得快，更容易超出保修限制。但看到几个实测，用到损坏寿命的写入量相比别家并没有更少。

远程桌面的话虚拟机就行了吧，独立物理机的必要性没那么明显。虚拟机可以通过虚拟化软件的共享文件夹功能访问特定宿主机文件。

非远程桌面方案，部署网页服务的笔记放在虚拟化环境，然后 https 向外网公开不就行了。不放心的话在 nginx 反代再加一层密码验证。

如果丢了有所谓，那还是要填真实的