本篇文章的阅读可以配合前序文章
nftables+clash打造透明代理时的dns处理问题
https://blog.mrtblogs.net/nfables-clash-dnsamsq-tproxy/
ocserv中通过route/no-route配置使得下发路由表到客户端，从而实现流量分流。大家一般通过该配置来选择哪些IP地址的路由需要到到服务端转发来解决路由流向的问题。
家庭宽带的上传一般来说比较小，或即使ocserv的服务端部署在大带宽服务器上，大家也希望尽量只有需要的流量才通过服务器中转，减少无用流量上VPN设备转发从而减少时延提升用户体验。但ocserv下发的路由表最多支持下发200条路由表。
为了尽可能的在200条路由表内塞下route或者no-route，大家发挥聪明才智通过合并cidr或者扩大cn的路由表范围等方式，有了很多优秀的no-route表，例如：
之前我也是通过这种方式进行分流，但使用中仍旧有很多不好的体验：
- cn-no-route部分时候在openconnect中无效
- 总容量200条，减去内网需要占用的条数，仍旧有较多路由重定向不准确
- 在客户端无法有效的排错该路由是否走vpn隧道
- 部分CN的IP如果想从vpn隧道通过，则改动非常大，且不一定能实现
我在部署本文引言中提到的透明代理时，突然想到，其实可以利用dnsmasq+clash的fake-ip功能一劳永逸解决分流的问题。
原理
Fake-IP定义可以参考 RFC3089 ，原理是客户端向clash服务端请求域名时，服务端会返回一个198.16.0.0/16的临时IP，并记录该IP与域名的对应关系用于后续发起请求时的访问。
有了这个原理，实现的过程就很简单了，只需要删除原来的所有no-route表，下发一个route表，涵盖内网IP段和198.16.0.0/16即可。
同时客户端的dns指向ocserv的dnsmasq的地址，设置需要调度到服务端的流量指向clash让其返回fake ip即可。
而dnsmasq分流没有ocserv的200条路由表（域名）限制，github上也有一个非常好的中国域名的解析列表。
使用方法为：dnsmasq的上游dns指定为clash的dns地址（若clash和dnsmasq在同一IP上，则需要修改clash的dns端口监听为非53端口，例如5353），配置文件使用如下仓库。
ocserv的配置修改如下：
此时重启ocserv服务端后，客户端连接后则正确按照指定方式分流了。
使用该方法的缺点是只能通过dns解析的方式对流量进行调度，无法对直接访问IP的方式进行调度，不过可以在内网搭建一个xio解析服务变相的解决这个问题，
但以上仍然无法解决硬编码的IP地址问题，这种情况只能通过本地增加路由表解决。
发表回复