软路由 路由器屏蔽广告原理介绍( 二 )


? 识别出来了 , 接下来就是拦截了 。拦截分两种:
? (1)域名方式 。上网哀求实际分两步 , 第一步 , 通过DNS解析域名返回目标服务器IP , 第二步 , 通过IP建立到远程服务器的TCP连接 , 使用HTTP传送内容 。域名方式就是在DNS做文章 , 发现哀求是广告哀求就直接返回域名不存在或者一个无效IP , 阻止TCP连接建立 。这种方式长处在于简便 , 快速 , 不介入正常TCP连接 。缺点是DNS只能获得域名 , 却不能获得完整的URL地址 , 因此无法对一些URL特征进行过滤 。好在现在广告普遍都是植入式 , 也就是普通站点嵌入一个指向广告的链接 , 通常广告都有相对清楚的域名(通常广告域名与访问站点域名不通) , 所以可以取得不错的效果 。这也是现在绝大多数方案的原理 。
? (2)流量过滤方式 。典型的如闻名的koolProxyR 。相称建立了一个TCP代理 , 所有流量走代理 , 代理可以拿到所有哀求的URL , 根据规则决定是否放行这些哀求 。长处是这种方式有可能获取完整哀求 , 可以进行超过域名的过滤 , 甚至等AI成熟后识别内容 。但也有缺陷 , 性能损失是一个 , 但绝对不是大问题 。最大问题是现在网站基本上都是HTTPS哀求 , 浏览器会校验目标网站证书 , 判定是否连接到了真正的地址 。这也使得传统的HTTP劫持几乎没有生存余地了 , 即使强行让浏览器连接到假网站地址 , 但假网站也造不出真网站的证书 , 浏览器也会报警 。目前日益普及的HTTPS严峻影响了koolProxyR类似过滤方案 , 因为它代理了浏览器发起的哀求 , 它只是一个到真正服务器的中转 , 因为连接内容完全是加密的 , 它无法看懂 , 甚至连网址都无法获得 , 导致它无法进行拦截 。
? 当然 , koolProxyR类似方案可以通过为每个目标网站制造一个假证书的方式 , 伪装成浏览器想访问的真网站 , 从而对URL及内容进行过滤 , 但这里会造成额外问题 。
需要为所有网站伪造证书 , 伪造证书的根证书比如放到每个浏览器的信任根里 。通常家里会有很多设备上网 , PC还好 , 平板 , 手机 , 家用摄像头、PS4、XBOX等等就麻烦了 。当然 , 还可以为这些设备设置白名单 , 就是不过滤 , 但无形中还是增加了维护难度 。某些应用不接受伪造证书 。典型金融类应用 , 各种支付 , 网银 , 银行应用 , 部分电商 , 它们会严格校验服务器的证书链 , 伪造证书根本不被接受 。这类应用在koolProxyR之类环境下是无法工作的 。? 所以 , 流量过滤方式不再是一个去广告的优选方式了 , 基于域名的方案已经成为主流 。
? 当然 , 还有一些基于浏览器插件的方案 , 也很有效 , 浏览器插件可以做到对域名 , URL , 甚至页面内容精细化过滤 。但问题是只能适用于浏览器 , 通常还是PC端 , 并不能像DNS方案一样 , 应用于整个家庭网络 。
? HomeLede固件采用AdGuardHome作为去广告方案 , 基于DNS技术实现 。DNS技术特征是对哀求的域名进行过滤 , 过滤的核心是规则文件 。类似于杀毒软件的病毒库 , AdGuardHome中可以挂载各类广告规则库 。其正确度取决于规则库 。
? 现在回顾一下开篇的问题 。
为什么启动了去广告还是可以看到广告? 规则库中没有屏蔽你看到的广告 , 或者这个广告和站点正文域名相同 , AdGuardHome根本无法去掉 。
? 广告升级了 , 目前规则库中并没有收录 , 无法屏蔽 。
为什么有些站点显示不了了规则库误伤了一些"正常站点" , 或者是规则库认为你访问的是广告 , 而你自己不认为(其实你之前一直认为是正常内容其实是广告链接)
现在都是https了 , 去广告技术没用了基于DNS去广告方案 , 与使用协议无关 。即使其他协议只要涉及到DNS解析也可以工作 。
碰到访问不正常时怎么办假如碰到站点访问不正常 , 想确认是否和去广告有关 , 怎么做?