好像不是过 24 小时，好像是每天 10:30 左右，正在使用的端口会被封掉，换个端口可以继续用，但是第二天 10:30 左右又有很大的概率会被封掉，于是不得不再换端口，如此循环次数不定后突然会有一天 Voilà过了时间没有被封，然后就会有相当长的时间不会被封，但是如果在这相当长的时间内主动重连，又会有很大的概率回到每天换端口的日子。这种情况大概是 22 年春天开始，是两年用下来的经验。现在是在服务器端将一大段 udp 端口范围重定向到 wireguard 端口，这样只需要在客户端换端口就可以了。另外，以上仅限 ipv4 ，ipv6 不会这样

不是用户太少，是用的户太少

不过话说回来，像 google domains 这样的用的户这么多的，也是说卖就卖的，何况 VPN 这种小众需求

这是分区背光，正常现象和品控无关。YouTube 上找些 hdr 看看就能看出和“便宜的电视”的区别了

@kyonn 或者说 anyconnect 客户端会帮助我们设置系统的 dns ，但是系统不一定接受客户端的设置，应用程序也不一定用系统的 dns 设置

@kyonn 理论上当然是 OP 以为的这样，实际上基本上也是这样。但是 split-dns 不是强制 dns 请求不到达其他接口（只是允许或拒绝其到达 vpn 接口），所以像 nslookup, dig 之类的，还是能够返回本地 dns 的结果的

@kyonn @ranaanna 抱歉前面第一句话可能没有说清楚，本来应该是“tunnel-all-dns, split-dns 分别是允许全部的和特定的 dns 请求通过隧道”。

@kyonn tunnel-all-dns, split-dns 都是允许全部（或特定）的 dns 请求通过隧道。如果希望 dns 分流，那么就不应该用 tunnel-all-dns 。另外，客户端的 dns 行为，到底是走隧道还是本地网络接口，还是要看操作系统和应用程序，并不是 tunnel-all-dns 就一定屏蔽本地 dns

1. 123 特别是 3 ，理解全部正确。
2. 4 ，既然 2 和 1 （远端内网能访问），说明 iptables 规则已经正确添加。

所以剩下的问题似乎只有：本地端的 dns 。它不会随着远端服务器配置的“指定的域名走指定的 dns”发生变化，需要自行设置。

@zjsxwc 很多年前的传言而已。曾经有研究显示暴露于高含量铝的人可能会患阿尔茨海默氏病，但是并没有其他和后续研究证实这个结论，所以到目前为止还不确定。铝是地球上最丰富的金属元素之一，广泛分布于水、空气甚至食物中。氢氧化铝和铝碳酸镁是很常用的抑制胃酸过多的非处方药。很多口服药含有氢氧化铝来保护胃黏膜。硫酸铝钾是食品添加剂。氧化铝不会和氯化钠反应，也不溶于乙酸之类的弱酸，所以不会但即使有“铝离子”析出，绝大多数会经消化道从排泄物中排出，少部分进入血液也会从尿液中排出，不会在人体蓄积，所以不会“长期摄入，老年痴呆”。当然，体内铝含量过高（见于肾病患者和服用含铝药物的儿童），可能会引起骨病、脑病和记忆力减退，但到目前为止，完全没有证据表明这些疾病和使用铝制炊具的相关性。

@zjsxwc 铝中毒？真有因为使用铝炊具中毒的？恐怕是严重低估可三氧化二铝的稳定性

似乎应该用复数

@ranaanna 实际上无非是身份验证方法而已。static keys 是用双方都预先知道的密钥来证明双方的身份是真实可靠的，这种方法在当今已经不再认为是足够好和安全了。所以一般用的是基于证书的身份验证，openvpn 的通常方法是用 easy-rsa ，生成自签 CA ，并在此基础上创建和管理所需的证书，从而产生一个 PKI ，形成一个相互信任的网络。这个小小的 PKI 仅仅是一个私有 PKI ，只在一个很小的范围内提供身份验证。当然，也可以使用公共 PKI （比如 Let's Encrypt ）提供的证书，但是这需要提供包括 common name 等信息，需要每个终端都要有独立域名，大多数公共 PKI 都是收费的等等，实际上完全没有必要。关于其他的“架构”，openvpn 还提供了用户名/密码的验证方式，但是一般是用在证书+用户名/密码的双重验证，单独的用户名/密码验证可以用--client-cert-not-required 强制，但是还是需要服务器的 ca

@fever PKI 可以说是建立 openvpn 配置的第一步。PKI public key infrastructure 公钥基础设施是指服务器和各个客户端都有各自的证书 cert 和私钥 key ，用来证明各自的身份； CA certificate authority 是指主颁发机构，本质上是一组证书和私钥，用来签署服务器和客户端的证书，保证所有的身份都是真实、唯一和可靠的。通常使用外部 PKI 需要付出一定的代价，所以 openvpn 提供了 easy-rsa ，用来部署自签的 CA ，给所有服务器和客户端颁发证书。所以 OP 认为 easy-ras 是生成证书的工具，理解也并没有错

@nkloveni 当前版本（ 2.6 ）还有这个选项，但是会有警告提示。2.7 版本是错误提示，但是可用--allow-deprecated-insecure-static-crypto 跳过。将来的 2.8 版本没有这个选项。pki ca 是有些复杂，但是好在有 easy-rsa ，跨墙有问题，但是这么多年用下来，似乎只要配置 tls-auth ，就没有问题。

再次抱歉看 OP 配置是有 tls-auth 的（但是不需要 0 1 ，因为不是点对点），所以可能的问题是两端用了相同的 cert 和 key

抱歉前面写错了，tls-auth 和 tls-crypt 是相似的东西，被封的是 tls handshake ，所以需要额外配置 tls-auth 或 tls-crypt

可能有一个错误：客户端的 cert 和 key ，不应该和服务端的是一样的，但是这里从文件名字来看，可能是一样的。简单的 static key 已经过时了。tls-auth hangshake 很多年前也被封了，但是 OP 只需要额外配置一个 tls-crypt ，给 tls-auth 加个密，就能顺利用到当下

@tool2d 用 INPUT 链试试看？另外，对于 UDP ，是不是要用 REJECT ？不然对方没有出错信息，只是以为“拦截不下来”

为什么一定要在 raw 表中定义 drop ？是出于 drop early drop fast ，从而减少系统开销的考虑？较早的时候 raw 表唯一的功能是给数据包一个 notrack ，所以也许是你的路由器在设计的时候并没有预料到你会这么早 drop 掉数据包？
何不在缺省的 filter 表中试试，给系统预设的硬件加速一个机会？