@v2tudnew
对，是可以 UDP 打洞，只不过各环节都要增加复杂度。比如在 BT 中，就需要一个没有防火墙的 peer 做中介。（ https://libtorrent-discuss.narkive.com/HqyhMO7B/libtorrent-does-libtorrent-support-hole-punching ）如果大家都指望打洞方案，那可连接性就可想而知了。
顺便一提，NAT-PMP 有支持 IPv6 的后继者（ Port Control Protocol ），但不太清楚目前路由支持的情况。

参考之前的永恒之蓝，微软已经发更新之后 WannaCry 才开始传播，而且主要是内网扩散。IPv6 回访攻击要能实现，对漏洞的要求应该更高。相比之下，防止应用程序漏洞的作用倒相对大一点。如果某程序开了没有限制来源的公网访问端口、通过了系统防火墙的许可、出现了未修复的危险安全漏洞、没有配置打洞机制或防火墙例外，同时用户主动访问的网站或中间的网关被攻击者掌握，且攻击者进行了扫描并正好知道这个漏洞，那有白名单防火墙会更安全。
我的意思是说，网关白名单防火墙的方案对用户和开发者增加了太多复杂性，但提升的安全性不大。操作系统的防火墙依然存在，所以掀屋顶的比喻不是很恰当，要我看更像是把围墙拆了变街区。

你提公共 WIFI 的场景我有点不理解。如果你在考虑把设备放置于陌生网络中的风险，那更应该加强设备自身的防护（零信任思想），而不是依赖网关来营造“安全”的边界。

@v2tudnew 主动暴露端口通过 IP 才能访问并不等于 DDNS ，例如 BT 、IPFS 、通话、对战等产品也用得上，不一定是专业级需求。
UPnP 和 NAT-PMP 是安全和便利性权衡的经典案例（ https://docs.netgate.com/pfsense/en/latest/services/upnp.html ），这表明自动配置端口的需求是广泛存在的，为此可以牺牲一点安全性。
用户访问恶意网站被回访，然后被攻陷的可能性当然存在。对于应用程序级的高危漏洞，如果已经存在 IPv6 时代的类 UPnP 机制，那也可能会被自动放通而中招，网关有没有防火墙可能区别不大。
至于操作系统的高危漏洞，这一般是大新闻（如永恒之蓝），有很多限制条件（比如 Win 防护墙 445 的入站规则限定为本地子网），会很快发布升级补丁。未公开的 0day 不太可能攻击普通用户。而且恶意网站的攻击需要有主动访问恶意网站的行为，不像 IPv4 那样会“躺枪”。所以我觉得风险是可控的，并不是为了方便而忽视危险的极端。
我主帖已经提到，服务端场景下 IPv6 地址是长期固定的。加之地址会被 DNS 公开，有一个高级的网关防火墙还是有意义的。

@v2tudnew
Win 的防火墙好歹还需要同意，UPnP 这种开了以后就是自动配的。你觉得开发者就不应该去管路由器防火墙，但是用户用不了首先会找开发者而不是路由器。即使 IPv6 支持比较好的那些路由器，想让普通用户简单学会也称不上容易，用户搞不懂说不定还是全部关掉了事。

安全与便利是一对矛盾，如何取舍需要智慧。我发本帖的目的在于指出，在 IPv6 下端口暴露被攻击的风险大大降低，而正确配置防火墙的门槛比 IPv4 NAT 还要高，否则很多 IPv6 的优势就无法发挥。对于家庭的应用场景，默认放通入站相比默认拒绝设置例外，对开发者和用户来说都是更好的权衡。在 IPv6 下还要搞防火墙，是不信任硬件自身的防火墙，所以再加一道额外防护措施的小众专业级需求，我觉得不应该成为通行做法。当然，各位分享自己的权衡考量，也有助于大家做出更好的判断。

@v2tudnew 监听端口向用户请求授权可以在操作系统内实现，比如现在的 Windows Denfender Firewall 。
IPv6 的高级防火墙即使存在，家庭用户中也只有很小的比例会配置。IPv4 时代的自动端口规则协议大多不适用 IPv6 ，即使未来出现了，那还要考虑不同路由厂家的支持情况、如何配置多级路由等。可以说 NAT 的老毛病很多都回来了。
IPv6 下的打洞相比 IPv4 NAT 确实会简单一点，但作为开发者，肯定还是希望少碰到这种事情。

@loopinfor 这就是我说的“主动访问被探测并发起回访”，也是隐私扩展提出临时 IPv6 地址的原因。

@delpo 典型的服务端需求建议用固定地址，典型的客户端需求建议用动态地址。但是还存在很多客户端需求比如 BT 、Sync 、VoIP 、PS4 ，他们既需要放通端口以提供便利，又可能有隐私顾虑不宜长期固定。家庭宽带的前缀本来就是会变的，如果不是要配置防火墙白名单，后缀的变动本来也不会增加多少问题。路由设成 DHCPv6 不是很推荐，因为地址空间小、安卓设备可能获取不了 IPv6 等，还不如直接固定后缀。

@LnTrx 更正：Windows 默认采用的是 RFC4941 的方案，地址随机但相对稳定。部分 Linux 类操作系统默认用的是 RFC7721 ，会随着网络环境（如前缀）而变化。

@delpo Windows 和部分 Linux 类操作系统的默认采用了 stable privacy addresses （ RFC7217 ），当网络环境变化时“固定”IPv6 地址的后缀也可能改变，需要用户配置才能改成 EUI64 或者固定值

顺便一提，如果防火墙只放通了固定地址，那主机内软件在开启端口时会面临两难：
1. 让外界连接临时地址，那么端口在外网无法直接访问，需要增加复杂性、引入 v6 打洞机制
2. 让外界连接固定地址，那么就相当于架空了隐私扩展，这样做的软件多了就可能关联身份

@fetich Linux 通常的做法是在 /etc/sysctl.conf 设置

net.ipv6.conf.default.use_tempaddr=2 （ https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt ）

不过我没有在群晖里试过

@cwek 物联网设备确实可能根本没有防火墙。不过这种物联网设备通常也没有隐私扩展，后缀是 EUI-64 定死的。
这么说我们需要的其实是黑名单防火墙（误）

@delpo 顺便一提，固定的后缀也会成为隐私的风险点，特别是个人电脑。
例如用户下载了某个不正经的 BT 种子，那 IP 地址的行为可能被记录甚至公开（比如 iknowwhatyoudownload.com ）。一段时间以后，用户又访问了某个正经网站，因为实名制，后台知道了你后缀和身份的关系。这样，之前的行为也可能与用户的真实身份相关联。在隐私扩展下，只有在相近的时间这样干才容易被关联。但如果使用了固定的后缀，那即便隔了一年也可以被关联，直到用户主动更换。
另外，EUI64 后缀包含设备的 MAC 地址，对厂商而言也是一个可用于追踪的信息。
所以如果使用防火墙放通固定后缀的方案，那可能得把需要放通的服务都集中在专门的设备（如 NAS ）与个人电脑隔离，并且仅把该设备的地址后缀固定成随机选定的值。

@delpo
安卓设备对防火墙的需要不大（ https://www.quora.com/I-know-I-dont-need-antivirus-for-Android-But-do-I-need-a-firewall ），更何况连蜂窝数据的时候也不可能去上级网关配置防火墙
我说的就是后缀的变化，PC 端要把设备的后缀固定成 EUI64 一般需要改配置，移动端则更麻烦

@acbot 有一个 IPv6 总开关就够了。

点对点直连才是互联网本来的样子。当用户被 IPv4 NAT 保护惯了，突然回到这种状态反而没有安全感，这才是反常。

SLAAC 的 IP 地址是变动的，本来就不太好配防火墙。精细的端口控制，留给那种 IP 地址固定的服务端场景就好了。

值得一提的是，IPv6 下不能再依赖 IPv4 NAT 环境所形成的陈规。如果端口映射还需要设计协议由网关设备来处理，那 IPv6 就有种搞了个寂寞的感觉。

IPv4 下端口暴露最大的风险是被别人扫到，但只要主机 IPv6 是 SLAAC 获取的，家庭内部终端被扫到的概率极小。
即使你主动访问被探测、回访，家用设备的现代操作系统通常自带有防火墙，正确配置的话风险不大。
网络中的网关设备（光猫、路由）有一定可能会被主动探测到。这些设备通常只向内网开放登陆界面，但如果魔改过的话建议测试确认一下是否配置正确。

https://github.com/awesome-selfhosted/awesome-selfhosted

这里面很多有 ARM 版，特别是社交类的占用很大，可以充分发挥 4C24G 的性能优势

@AllenW 本来就是月啊

如果公司明确告知过，那还是要公私分明
如果不是，那就涉嫌违法了

个人文档集中存放，重装时转移就好了

Port knocking 符合要求么

发的和测速记录里的有啥区别