旁路由 ipv6 怎么解决？

@ppbaozi #39 我知道你说的意思，大家都解析到准确的 IP ，然后通过准确的路由去到目的地。
但我的意思是爬墙的流量根本不需要解析真实 IP 。
请看这篇文章。https://blog.skk.moe/post/what-happend-to-dns-in-proxy/

既然不需要解析到准确的 IP 。那么就也不需要解析到 ipv6 地址。那使用旁路由方案的话，就可以让主路由根据路由表转发 fake-ip 给 openwrt 即可。

因为根本不需要考虑 ipv6 是否能过墙，因为代理工具只需要将流量转发给梯子服务器，服务器会根据目的地解析最终的 ip 地址。

```
Fake IP 的定义出自 RFC3089 。这个 RFC 定义了一种新的将 TCP 连接封装成 SOCKS 协议的方法。

浏览器自己都有 DNS 缓存机制，因此浏览器会先开始寻找自己的缓存，不过并没有找到 blog.skk.moe 的解析结果
浏览器通过调用操作系统的 getaddrinfo 方法，向操作系统寻求解析结果
操作系统自己也有一层 DNS 缓存，但是现在操作系统从自己的缓存中依然找不到这一结果
在系统的网络设置之中设置了一个专门的上游 DNS 地址，可能是用户手动设置的也可能是代理客户端设置的。不论如何，这个设置最终会使操作系统向代理客户端发起 DNS 请求
操作系统发出的 DNS 解析请求会经过代理客户端并最终被截获
代理客户端从解析请求中获得域名，从 Fake IP 池中选取一个 IP 建立映射
代理客户端将这个 Fake IP 返回回去，操作系统拿到了这个 Fake IP 并返回给浏览器
浏览器对 Fake IP 建立一个 TCP 连接并发送出去
这个 TCP 连接被代理客户端截获。代理客户端抽取出 Fake IP 并反查出这个 TCP 连接中对应的域名
有了 TCP 连接和域名，代理客户端可以轻易地将其使用 SOSCKS5 或者 某种协议 进行封装
有了 Fake IP ，代理客户端无需进行 DNS 解析。最后不论是浏览器、代理客户端还是远端服务器都不会去和 Fake IP 进行连接，因为在代理客户端这里就已经完成了截获、重新封装。
---------------------
本文著作权归作者 Sukka 所有。本文采用 CC BY-NC-SA 4.0 许可协议，商业转载请联系作者获得授权，非商业转载请注明出处。
作者：Sukka
来源：浅谈在代理环境中的 DNS 解析行为
链接： https://blog.skk.moe/post/what-happend-to-dns-in-proxy/
```

但是使用了 fake-ip 方案后，导致所有的 DNS 都拿到假的 IP 地址，所以就需要 DNS 分流来解决这个问题。

当然，如果用回 openwrt 当主路由，然后配置好支持 ipv6 访问，那么当然也能解决问题。但这 OP 不是说 openwrt 不知道何种原因影响了 PT 和 PCDN 吗，不是所有人都看得懂 openwrt 那个又臭又长的 iptables 规则链的。openwrt 自己的插件本身也有很多插件之间的兼容问题。所以很多人会采用硬路由转发到 openwrt 旁路由的方案来解决稳定性问题。

所以才有了我所说的 DNS 分流。

1 、不需要管爬墙的流量是否能解析到 ipv6 地址，因为现在爬墙的代理过程根本不在乎你拿到什么 IP 地址。他们是根据你的访问域名发送给梯子服务器，再由梯子服务器发起链接给目的服务器的。
2 、既然需要管爬墙流量是否需要解析到 ipv6 。那么我们只需要确保国内的 ipv6 地址能解析到准确的地址，并准确的转发出去即可。
3 、这种方案在旁路由拓扑中，开销是最小的。DNS 开销小，路由转发路径小。传统的旁路由方案其实就是二级路由或者 dhcp 把个别机器配成二级路由，这些方案都不方便管理。
4 、方案的缺点就是 DNS 可能存在单点故障，需要额外的监控脚本来修改主路由的上游 DNS ，如果 DNS 炸了，将会影响整个网络的 DNS 查询。

@bobryjosin 如果梯子插件支持 ipv6 透明代理，海外落地 vps 也有 ipv6 ，可以试试开启这个选项，但是如果不使用 ipv6 nat ，分流可能不会太准确

@neroxps #41
2 、既然不需要管爬墙流量是否需要解析到 ipv6 。那么我们只需要确保国内的 ipv6 地址能解析到准确的地址，并准确的转发出去即可

@neroxps 那不就是指向旁路由设备，我记得 clash 自带的 dns 服务和 smartdns 这类的 dns 服务是类似的。如果用旁路由设备是有点多此一举的。

@SenLief #44 但国内流量不走旁路由啊。你也可以用一个 arm 盒子或者一个巴掌大的路由跑一个 DNS 这样这种 DNS 炸的几率就小很多了。例如 GL.iNet 的 GL-MT300N-V2 那种巴掌大的。单独跑一个 dns 卓卓有余

@neroxps 我也是 ros+clash(debian),想确认 2 个问题
1:ros 的 dns 配置的是不是 clash 的 dns 服务
2:ros 的 dns 服务是不是只配置一个同时忽略 pppoe 的 peer dns
3:在你说的方案下,是不是需要人为维护需要过墙的域名列表,同时再维护一份 clash 的分流列表

@redial39
1 、ROS 的 dns 配置是 coredns ，coredns 上游有两个，一个是运营商的 dns ，一个是 clash 的 dns 。coredns 的插件有读取网上的规则。我用的是这个 https://github.com/blackmatrix7/ios_rule_script/tree/master/rule/Clash ，当匹配到 proxy 规则的话就从 clash 查询 dns ，不匹配就从运营商 DNS 查询。（这里也可以配成 smartdns 再做测速返回最优 IP 也可以）

2 、ros dns 只配置一个，我是写了一个 Mikrotik 来解决当 dns 服务器炸了之后，把 ros 的上游 dns 切会运营商 DNS 。https://github.com/neroxps/RouterOS-Script/blob/master/Clash_dns_check.rsc

3 、我上面 1 里说了。我用的 coredns 插件支持各种网上的规则文件，dnsmasq 的 ag 的 clash 的 自动更新订阅。https://github.com/charleyzhu/coredns_wormhole_plugin

旁路由不是标准的网络架构，所以。。。

@hcwhan 看了这个后，我倒是想，其实可以简单点，主路由搞 2 个 lan ，lan1 、lan2 。
lan1 直接给不需要爬墙的设备用。
lan2 下面挂旁路由（二级路由），给需要爬墙的用。
lan1 、lan2 不同的 vlan 。同时接 ap ，ap 也搞 2 个 vlan 对应 2 个无线 ssid 。

现在主路由（拨号）、旁路由都是 pve 的虚拟机。没有物理交换机，另一个刷了 op 的物理路由器作 ap 。

应该可以实现把。

@neroxps 那实现的话是不是在 ros 的 mangle 里吧 src 为 fakeip 段的打上路由标签,然后在路由里强制下一跳是 clash,这样的操作?如果可以的话能不能给一下样例配置,感谢

@redial39 #50 我以前是打标机的，后来发现不需要打标记，直接用路由表更高效。

估计要把 ipv6 再分下去。让 ipv4 和 ipv6 都走到旁路由。

基于现有 v4 方案搞。
例如以前是 ipset+iptable+clash ，现在就是 ipset+ip6table+clash 。
clash 只需要跑一个。

@daveh 主要是要让终端的 IPv6 路由到旁路由。

软路由把 gfwlist 里的 AAAA DNS 请求关掉，比如用 smartdns ，我现在就是这样的

@zhaidoudou123 #55
简单来说，需要爬墙的设备 dns 网关都设置成旁路由，旁路由里开个比如 passwall ，把 passwall 的 dns 上游设置成 smardns ，smartdns 再把 AAAA dns 请求都关掉就行了

另外，不知道 OP 的设备是不是苹果设备，苹果设备会请求 type65 的 AAAA 记录，可能会与 IPv6 相关
具体可以参考我之前的帖子：
/t/797235

我是设备自身进行代理的，主路由就正常上网不翻墙。
旁路由翻墙透明代理给 nvidia shield 用，由于 OpenClash 的 ipv6 有 bug 所以直接放弃了

@zhaidoudou123 感谢分享，终于知道怎么回事了，我就是在旁路的 OpenWRT 上屏蔽了 AAAA 记录之后 iOS 上访问本站时就会出现 SSL Error 的问题。 我这就去重新编译个带 SmartDNS 的固件。

@neroxps 就你这是最正确的了。我建议用 dnsmasq-china-list 项目，makefile 可以生成各种 dns 配置文件。境外域名全走 clash 。这样 clash 只需要 geoip cn direct ，其他全部 proxy 。只需要维护 dns 域名列表就好了，clash 都不用维护了。