DNS解析的污染题目和 fake-ip 代理模式

之前用 openclash 设置好的 OpenWRT 路由在工作了一年多之后, 近来开始经常出题目, 尝试了各种方法: 重设订阅, 修改规则, 升级 openclash, 都无效, 终极重置系统, 重新装了最新版本的 openclash 之后网络是恢复了, 但是惊讶的发现所有的域名请求返回的都是 198.18 开头的假造IP, 表现的代理模式为 fake-ip. 出于好奇学习了一下这种新型的代理模式和工作方式.
DNS 解析的污染题目

众所周知的缘故原由, 平时使用的DNS解析结果是受到使用的. 下面通过三个差别DNS服务器114.114.114.114, 223.5.5.5, 8.8.8.8 查询 youtube.com 的解析, 可以看到只有 8.8.8.8 看起来比力靠谱, 114.114.114.114 和 223.5.5.5 都是被污染的结果.
通过 114.114.114.114

1. $ dig www.youtube.com @114.114.114.114
3. ;; QUESTION SECTION:
4. ;www.youtube.com.                IN        A
5. ;; ANSWER SECTION:
6. www.youtube.com.        602        IN        A        31.13.106.4
8. ;; Query time: 25 msec
9. ;; SERVER: 114.114.114.114#53(114.114.114.114) (UDP)

复制代码

通过 223.5.5.5

1. $ dig www.youtube.com @223.5.5.5
3. ;; QUESTION SECTION:
4. ;www.youtube.com.                IN        A
5. ;; ANSWER SECTION:
6. www.youtube.com.        11        IN        A        199.16.158.8
8. ;; Query time: 4 msec
9. ;; SERVER: 223.5.5.5#53(223.5.5.5) (UDP)

复制代码

通过 8.8.8.8

1. $ dig www.youtube.com @8.8.8.8
3. ;; QUESTION SECTION:
4. ;www.youtube.com.                IN        A
5. ;; ANSWER SECTION:
6. www.youtube.com.        300        IN        CNAME        youtube-ui.l.google.com.
7. youtube-ui.l.google.com. 300        IN        A        142.250.66.78
8. youtube-ui.l.google.com. 300        IN        A        142.250.196.206
9. youtube-ui.l.google.com. 300        IN        A        142.250.77.14
10. youtube-ui.l.google.com. 300        IN        A        142.250.204.46
11. youtube-ui.l.google.com. 300        IN        A        142.250.198.78
13. ;; Query time: 49 msec
14. ;; SERVER: 8.8.8.8#53(8.8.8.8) (UDP)

复制代码

网络的连通性大部门代理工具已经解决的很好, 如今代理工具的难点, 主要都是在和DNS污染作斗争.
常见的代理模式

socks5 / http 代理模式:

• 全局代理时, 应用的请求不解析DNS, 直接全部封装网络包走远端代理
  
• 假如设置了分流规则, 则满意规则的走远端代理, 用代理端情况的DNS解析, 不满意的走本地直连, 用本地DNS解析
  
• 这种方式不是透明的, 假如应用不支持代理就不能使用
  

tun 模式:

tun 模式类似于假造网卡, 在网卡层接管流量, 代理对于应用是透明的, 应用感觉不到代理的存在, 不支持代理的应用也能使用.

• 应用请求网络时, 需要先解析得到 IP 才可以发起毗连. 解析依然用本地设置的DNS, 如许得到的IP地址很轻易被污染.
  
• 即使设置成远程的DNS也轻易得到污染的结果, 并且影响访问速率.
  

redir-host 模式

redir-host 模式是 tun 模式的一种改进, tun 模式工作在第三层网络, 看不到请求的域名, 只能看请求的 IP 地址, 假如要根据域名规则分流, redir-host 模式的实现方式就是拦截 53 端口的 DNS 请求, 建立一个映射表, 在终端发起请求的时间匹配访问的域名, 再举行规则分流. 但是假如多个域名指向同一个 IP, redir-host 的规则判断就会出题目, 这时间这个IP上的访问要么全走远端, 要么全走本地.
fake-ip 方式

fake-ip 方式也属于 tun 模式的一种改进, 但是变化很大

• 在应用访问时, 代理工具立即返回一个假造IP, 并记录这个IP和请求域名的映射关系"somedomain.com" -> "198.1.0.11", 当应用对 198.1.0.11 发起毗连的时间, 代理工具将请求转换为 somedomain.com 并根据规则判断, 假如满意条件就走远端DNS解析, 否则走本地DNS解析.
  
• 和通例模式对比: 通例模式应用需要解析出IP后才会毗连, 之后再走规则, 但是这第一步解析会产生很多的不确定性, 使用中的很多题目就是这一步当中产生的, 而 fake-ip 模式可以让毗连和走规则在解析IP之前完成, 避免了通例模式下的不确定性, 提拔了访问效率.
  

fake-ip 的题目

• 应用端的域名访问看不到真实IP了
  
• ICMP题目: 非TUN情况下(如iptables redir), fake-ip 不能 ping 通, 也会造成一些题目, 比如 traceroute 不能用, 应用检查服务器连通性不通过等, 常见题目有游戏掉线, 游戏加快器测速不通过等.
  
• 应用能够通过对比DNS解析结果知道是否存在代理, 部门应用会禁止使用 fake ip 并产生警告.
  

最佳实践

clash规则有两种策略方式, 白名单方式和黑名单方式
白名单方式: 域名白名单 + 直连兜底

1.   - DOMAIN-SUFFIX,square-enix.com, PROXY1
2.   - MATCH,DIRECT

复制代码

如许只有指定的域名请求可以走代理, 其它的情况都是直连
黑名单方式: 域名黑名单 + 代理兜底

1.   - GEOIP,CN,DIRECT
2.   - MATCH,PROXY

复制代码

这时间只有辨认为直连的规则才走直连, 其它情况默认走代理
个人比力倾向于白名单方式, 由于平时使用, 只有少数域名需要走代理, 而且如许配置的规则要简朴不少. 对于 fake-ip, 由于对于技术人员很多时间解析真实IP是刚性需求, 以是 fake-ip 不能用于主路由, 可以在主路由下的无线AP上安装, 需要的时间使用.

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。