运营商劫持(DNS/HTTP302)
本人以网络技术出身，近两年接触CDN网络，处理了一些CDN方面的网络问题，大多数以运营商丢包，延迟抖动为主，也处理一些硬件故障，比如机械硬盘的读写io测试，内存条兼容性测试，服务器IPMI规划等。这篇文章打算把自己对运营商对资源请求的劫持写下来，这个其实不是很罕见的事例，也不是网上找不到解决办法，也不是无法理解的尖钻技术，只是罗列一下自己的所知。
CDN网络访问拓扑
既然提到了CDN网络，那就顺带提一句吧。
废话不多说，先上图。
这回可以开始废话了吧？：大体的工作逻辑有用户的访问、localdns的解析、CDN资源调度、资源应答。
如果按照这种方式去运营CDN架构，估计CDN行业早就倒闭了，先不说资源调度的好坏，如果有恶意的攻击流量，整个CDN系统就直接可以GG思密达了。
所以我这里也只是为了阐述运营商劫持行为，简单的说明了一下CDN网络，读者千万不要认为CDN如此的简单，CDN需要更多更强大的调度系统、数据监控系统、nginx、lvs等系统技术（我也就知道这些了）。高端的CDN厂商还有自建专线、自建IDC、甚至用到了ISP的骨干策略MPLS-TE。这些都是不可小觑的技术，详细的CDN知识我就不卖弄了，毕竟我只是做网络的，对系统部分还很薄弱，喜欢了解的读者可以阅读《CDN技术详解》来增长对CDN的见解。
运营商劫持概述
劫持的目的
其实目的很简单，关于运营商劫持，一般运营商也不是无故做劫持，毕竟他们维护服务器，维护相应设备（比如分光器、分流器）也需要成本，运营商主要劫持出省流量，对于“小”运营商来说他们有省内流量考核，跨省访问会增加成本输出，集团控制出省流量，所以劫持往往发生在省间传输上。其次所有运营商都可能会做劫持，目的是减少省骨干网络链路的负载压力，尽可能的减少中继链路、远距离骨干链路，负载能力弱的链路上的流量，则会出现劫持的现象。
劫持的方法
运营商/或者小区宽带会有分光器设备，因此可以把用户请求流量进行映射，从而获取用户请求响应，即可达到用户需要什么，然后再根据抢先建立HTTP连接，优先传给用户数据，这样真正提供资源的服务器返回来的数据就自然的被丢弃掉了。
劫持的演变
劫持的逻辑，慢慢的转化为了目前的CDN厂商在做的事，当然CDN厂商的流量调度主要是为了解决客户资源的分布式访问，避免用户访问资源时长时间等待。我也是在接触CDN网络以后，才慢慢接触到了运营商劫持，运营商主要的劫持动作还是修改访问资源的ip，也就是域名302了。
劫持类别
劫持大可分为三类：
– DNS解析劫持
– 域名302劫持
– NATip劫持
关于DNS劫持
DNS劫持也可以理解为用户的请求去往了错误的DNS服务器进行查询解析，返回来的目的主机IP自然不是我们想要达到的资源服务器主机，这往往发生在用户请求的第一步，目前在鹏博士网内遇见的比较常见。
长宽资源经常出现被劫持和转发错误的现象。解决办法如下：
1、把转发列表写到named.conf文件里，更新我们的转发ip
2、然后编写策略针对我们要去的域名从BGP出口出去，防止NAT。
x.x.x.x.com，（绑定hosts： xxxx.xxxx.com ）
zone "cdnxx.com" {
type forward;
forward first;
forwarders { x.x.x.x;x.x.x.x;x.x.x.x};
};
zone "cdnxx.com" {
type forward;
forward first;
forwarders { x.x.x.x;x.x.x.x;x.x.x.x };
};
场景1：
DNS服务器为本地运营商的DNSip，但是解析到的目标cache是其他省市的ip。
原因是转发或者nat没有做好，没有转发到我们指定的DNS服务器上进行解析，或者从nat口出去，改变了长宽的源地址。
场景2：
DNS服务器为本地运营商的DNSip，但是解析到的目标cache是本省市的ip。
原因是本地运营商有cache缓存，相当于小型的CDN节点服务器（浏览器的cookie），要把我们需要的域名添加到缓存黑名单里，不进行本地缓存。
场景3：
DNS服务器为本地运营商的DNSip，但是解析出来的ip，有时候是正确的，有时候是其他运营商的。
原因是该地市有多个cache服务器，需要在缓存服务器里把所有的转发ip和域名都做好缓存黑名单。
运营商解决时需要添加的列表：
ixcache缓存设备 panabit（流控）把不做缓存的域名加入到名单里。
场景4：
DNS解析有时候成功有时候失败。
原因是长宽本地会有缓存服务器，之上有一个缓存控制器，如果我们的解析被缓存服务器命中，就会本地直接返回结果，所以要在控制器上做策略，禁止调用到缓存。
其实我在排版的时候一直在纠结，我这个图应该放在这部分的前面还是后面，左右了半天还是决定贴在后面吧，这样不会冲乱DNS forward的配置。
关于域名劫持HTTP302
HTTP302即为：访问的资源暂时性转移，得到新的资源位置，然后重新访问获取资源。
这其实就是典型的CDN运营架构了，CDN的资源调度就是这么去做的。假如北京的用户需要访问某个网站，CDN公司得到网站方的授权后，就会把直接访问的URL做CNAME跳转到CDN调度服务器上，接下来根据区域localdns的识别将北京的用户请求，调度到就近的节点进行服务。
那么，CDN可以利用HTTP302进行调度，那么运营商“更”可以这么做了，这里说的“可以”中心意义是运营商有着近水楼台的优势，在IDC出口方向可以把流量做镜像到自己的服务器上，该服务器可以将URL上的资源提取出来，然后查找自己的数据库、存储资源是否有该资源，如果有那么就会302到自己的服务器上，为用户提供资源，从而拦截了正常的请求响应。如果没有该文件，运营商通常会统计资源的热点程度，毕竟运营商的存储设备也不是无限大的，为了提高利用率肯定要优先缓存访问量高的文件。接着刚才的说，如果存储设备里没有该资源，那么运营商会监听这个请求流，直到请求返回应答，这样自己在本地也就可以备份一份资源了，如再有请求过来，就可以直接吐给用户数据。这样就做到了劫持。
当然，再进一步讲，劫持动作可以做到你家门口，原理、意义，同上。
解决办法
原理和现象比较好说，但是说到解决办法其实并没有什么主动出击，考自己攻破的方法，只能求爷爷告奶奶的去找我们的IDC机房，让他们把我们劫持的现象(HTTP302)、诉求、相关数据上传到集团哪里，找到相对应的人员才可以解决。运营商一般处理办法就是在他们自己的缓存设备上把劫持的域名加入白名单，然后清除缓存。这样再过来请求的流就不会被劫持了。
我还见过其他方式的劫持，不是运营商自己做的，而是和竞争厂商一起做的，比如A公司和B公司为行业利益相争的友商，不凑巧的是A公司的实力比较雄厚可以收拢运营商的人，或者某个IDC机房的人，在机房出口或者小区出口架设分流器等设备来采集通过的业务流量，一旦流量被匹配上之后也直接做劫持，这种情况再工作中虽然不常见，但是只要遇到解决起来极其的费劲
我们应该向客户说明情况并收集一些证据如劫持证据、证明CDN授权、监控数据等。
联系劫持ip归属地的IDC机房负责人或者运营商的人来说明情况。
有些运营商也建议直接找当地公安局、网警进行报案，并配合处理。
自行去当地机房查看设备情况，一同排查内部架构。
找到被劫持的友商了解情况，通过公司高层、集团领导出面处理。
技术过硬的话可以采取HTTPS进行加密传输，或者其他技术手段避开数据采集。
最后一点，希望以上建议可以解决问题，如不能，请看下一条。
最最后一条，终极奥义！以其人之道还治其人之身！
收个尾巴
暂且，个人对运营商劫持的理解也就到这个层次，但是我相信，在我职业生涯中这里面的猫腻肯定不是只有这些，运营商想搞事情，谁拦得住？！
2017年10月25日
工作中遇到新的劫持现象，http状态码499突增。
我先说现象：
抓包看到，客户端有request请求包过来，然后按理说服务器需要回response返回给客户端，但是随即又收到了客户端发来的RST这就表示客户端又把连接关闭，起初排查时候认为是下载速递有影响导致客户端等待不及就把连接手工断开了，或者是客户端的故障导致重新建联，随后找到运营商那边了解情况，发现业务访问没有影响，细查后发现是有缓存设备。
缓存原理：
当客户端（真）发起请求时，经过一系类的dns解析、调度来我们服务器，然后建立tcp连接后准备请求数据，然后缓存服务器进行数据流分析，根据文件类型做匹配，如果匹配到缓存服务器中有该请求文件，则做2个动作，第一是返给客户端302跳转到自己的缓存存储服务器上请求数据，第二是模仿客户端的ip地址向真正的业务服务器发起断开连接，服务器会认为客户端（假）取消了建联，进而切断了真的客户端与服务器之间的数据交互。然后缓存服务器把资源吐给客户端。
排查后就需要联系缓存业务的人员取消劫持，只是在排查过程中很难发现有“中间人”在从中捣乱。