同被 ban，看下个月不解的话，只能花 3 刀换 IP 了

理论上可行，类似于 RAID5 组盘或者 RAR 里的恢复记录，就是靠牺牲数量（带宽）来保证质量。

起初我以为是别人的问题，因为 trace 之后过了墙，但后来发现我错了。动作并不是不让你出去，而是不让目标进来。
确切的说就是“源地址检测 drop 包”，所以从内发起的 trace 里体现是最后一跳无响应，从外发起 trace 则是过墙后无响应。

后来想了一下，看来是针对$$特征检测导致的，所以尽量使用支持 AEAD 的加密方式吧。有可能的话尽量混淆一下。

@hlz0812 就是域名还能解析，没被污染。我换个 IP 改下 DNS，域名还能用的意思。

简单说吧！

条码支付其实格式上是有潜规则的，基本上是前 2 位用来识别这个条码属于哪个支付公司的。因为有很多聚合支付的商户，具体举例：麦当劳、全家，统一入口扫码，自动路由去请求支付授权。

所以，第一种，商户联机核销的条码。这种条码除了标识头以外，中间大概会分成 token 类似于挑战码，后面几位应该是类似于应答值。

上面有人说的一次性口令的实现其实是不严谨的，因为单纯一次性口令的前提是必须知道对方的身份。否则，给你一串条码你去几亿用户里比对？

那么如何从几个数字的条码里识别用户？这才是条码支付的核心。那么就必须提前把身份信息注册到条码里，也就是说客户端在联机的时候，预先向服务器里申请 token，这样某一个 token 被谁申请了，服务器自然就记录了。当然这还不足，如何鉴权，那就必须在服务器上和客户端里进行相同的操作，无论是 HMAC 还是预共享密钥，这个随便了，得出的结果就是后面几位的应答值。

当然，十来位的条码肯定是不足的，那么 token 段必然是多用户共享的，也就是一个 token 是可能被多个用户一起注册的，但是我们可以从 token 里知道有哪些用户在用，然后通过检索每个用户的应答值就可以完成鉴权动作了。所以这里就存在一个风险，一个 token 最大同时共享给多少人可以控制在可接受的风险范围？这些就是数学问题啦。

第二种，双方离线的二维码。

这个其实就是和公交卡一样的原理，感觉没什么可说的。大家有共同的密钥或者基于 PKI 的鉴权，生成账户支付码（无外乎就是金额、账号之类的，需要时效性就再加一个有效期），设备检查通过就可以了。反正要预先充钱，事后再记账罢了。


以上均为个人想法，欢迎探讨。

@hlz0812 如果连 ping 这种 IP 层协议都禁掉了，就没有需要去试端口了，准备掏钱换 IP 了 o(︶︿︶)o