The distinguish of ios and android device traffic through cluster

一．Mobile 为什么需要vpn

（1）如果没有vpn，mobile用户流量怎么导入到cloud里面？mobile用户不像pc终端一样可以安装endpoint或者直接在浏览器里面设置代理服务器，所以我们需要一种方案可以把pac file url的地址使mobile知道。

（2）经过vpn服务器处理的流量，http头部里面都加入了x-ws-auth字段，方便被proxy server认证.

二．iOS device

1.拓扑

10.250.70.111是mvc的地址，这个地址通过ifconfig查不到，使用ip a来看

2.包结构

（1）首先mobile打开浏览器，输入网站地址，这个动作会触发vpn连接（为什么vpn会连接？因为vpn隧道保护的是所有流量，所以vpn会自动启动）。浏览器从vpnprofile中获取pac file url地址，然后去这个地址获取pac file的内容。然后将要访问的网站地址和pac file的内容进行匹配，如果匹配到了，就直接返回了proxy的地址。

（2）浏览器知道了proxy的地址应该是“webdefence-cn-mobile-it.odd.blackspider.com:8081”，然后使用dns去查找这个域名的ip地址，因为有vpn隧道，所以这个查询的流量应该传到cluster里面。首先我们pingwebdefence-cn-mobile-it.odd.blackspider.com看看回显的地址是多少？

[root@mvc01o ~]# ping webdefence-cn-mobile-it.odd.blackspider.com

PINGwebdefence-cn-mobile-it.odd.blackspider.com (10.32.14.73) 56(84) bytes of data.

64 bytes from 10.32.14.73:icmp_seq=1 ttl=64 time=0.189 ms

 可以看到这个地址是10.32.14.73，所以ios mobile出发经过vpn隧道的流量的目的都是10.32.14.73.

（3）因为流量需要经过vpn隧道，所以数据包再进行封装，在原数据包的前面加上vpn隧道两端的ip地址，以及esp头部。封装之后为

新源ip（10.32.145.136）----新目的ip（10.250.70.11）----ESP----源ip（10.32.145.136）-----目的ip（10.32.14.73）

这是在fw上抓的经过esp加密的数据包

（4）当流量到达mvc之后，mvc解密并且解封装该流量，解封装之后数据包的格式为：

源ip（10.32.145.136）-----目的ip（10.32.14.73）

 

（5）然后进行数据包的重组，将数据包的源ip改成自己的出口ip（因为数据包的源ip是10.32.145.136，这是一个私网地址，对于prx来说它并不认识这个地址，所以需要将数据包的源ip进行更改），也就是10.250.70.111，目的地址依然是proxy的地址10.32.14.73，并且在http头部中加入x-ws-auth，在mvc上抓包。

但是抓到包的目的地址是10.250.42.10，why？？？？？？？？10.250.42.10不是fw的接口地址吗？目的不应该是10.32.17.73吗？？？为什么跟分析的不一样呢？

想了好久，终于想通了原因！！！！

回到上面的第（2）步，使用dns到cluster里面去查找“webdefence-cn-mobile-it.odd.blackspider.com”的ip地址，觉得应该是10.32.14.73。仔细想想，当查询dns的流量被mvc解密之后，mvc会把流量传到dns server去解析这个域名对应的ip地址，但是这个dns查询流量在到达dns server之前，会经过fw，fw是一个load balance，fw会直接回复自己接口的ip地址，因为这个域名“webdefence-cn-mobile-it.odd.blackspider.com”的proxy是fw load balance的一部分。所以mobile得到的dns应答的ip地址应该是fw的接口ip地址“10.250.42.10”，所以从mobile到vpn server的流量不是

新源ip（10.32.145.136）----新目的ip（10.250.70.11）----ESP----源ip（10.32.145.136）-----目的ip（10.32.14.73）

而应该是

新源ip（10.32.145.136）----新目的ip（10.250.70.11）----ESP----源ip（10.32.145.136）-----目的ip（10.250.42.10）

X-Ws-Auth

The algorithm looks like thefollowing:

Function string AES (stringData, string key);

Encrypted Blob = AES (Blob,  AES(“www.google.com”, “Shared secret”));

 

Decrypted Blob

Username，Device id，UDID etc

（5）流量到达了prx之后，prx首先验证x-auth头，如果验证通过（判断该使用default policy，还是specific policy），则prx查看htttp get 头部，如果这个website跟web category里面的想匹配，并且action是deny，那么prx将会发送一个code 200 forbidden给mvc，然后mvc通过vpn把网页内容传给mobile。在prx上抓包tcpdump -i any port 8081 -s 0 -w    *.cap

 

3.总结

Fw-ip:10.250.42.10

Mvc_ip:10.250.70.111

Prx:10.250.0.171

Vpn（解密之后的流量）---fw----prx---fw

Mvc： 10.250.70.111------》10.250.42.10

Fw ： 10.250.70.111-------》10.250.42.10

            10.250.70.111------》10.250.0.171

Prx：  10.250.70.111------》10.250.0.171    

流量从mobile出来经过vpn到达mvc，mvc处理数数据包，把流量传到fw，fw处理数据包，通过load balance策略把数据传到真实的prx，prx认证用户并且匹配policy，然后根据policy的action来决定下一步动作。

三．AndroidDevice

1.拓扑

2.包结构

（1）跟ios device一样，先取pac file，然后去查询pac file中域名的ip地址。但是android device 跟ios device不一样，从ios device出来的流量都是要经过vpn隧道，然后流量被vpn server解封装，而android device的vpn隧道就在device里面完成了，所以出来的流量还是明文的，所以查询域名的dns server并不是cluster里面的netboot服务器，而是mobile device设置的dns server，所以这个域名“webdefence-cn-mobile-it.odd.blackspider.com”的ip地址就是10.32.14.73。从mobile发出的流量为：（http头部里面也是有X-Ws-Auth）

源ip10.32.145.159-----》目的ip10.32.14.73

（2）因为数据都是明文的，所以fw可以直接抓包tcpdump -i any port 8081 -s 0 -w *.cap

当fw收到去proxy的数据包的时候，还是要使用load balance的功能，所以fw会把目的ip修改为proxy真实的地址10.250.0.171

初始数据包

源ip10.32.145.159-----》目的ip10.32.14.73

Fw load balance之后

源ip10.32.145.159-----》目的ip10.250.0.171

（3）在mvc上抓包，发现没有任何8081的流量，说明andorid device的流量不会经过mvc，因为vpn在mobile本地被封装和解封装了。

（4）在prx上抓包tcpdump -i any port 8081 -s 0 -w prx_8081_android.cap

3.总结

Pac_file_ip:10.32.14.73

mobile_ip:10.32.145.159

Prx:10.250.0.171

 

Fw：10.32.145.159---à10.32.14.73

          10.32.145.159---à10.250.0.171

Prx:   10.32.145.159--à10.250.0.171

流量从android mobile经过vpn封装、解封装以及添加x-ws-auth头部之后到达mvc，mvc处理数数据包，把流量传到fw，fw处理数据包，通过load balance策略把数据传到真实的prx，prx认证用户并且匹配policy，然后根据policy的action来决定下一步动作。

------------------------------------------------------------

1.      Mobile Security

为什么需要vpn？

（1）     如果没有vpn，mobile用户流量怎么导入到cloud里面？mobile用户不像pc终端一样可以安装endpoint或者直接在浏览器里面设置代理服务器，所以我们需要一种方案可以把pacfile url的地址使mobile知道。

（2）     经过vpn服务器处理的流量，http头部里面都加入了x-ws-auth字段，方便被proxyserver认证.

2.      iOS device

 

10.250.70.111是mvc的地址，这个地址通过ifconfig查不到，使用ip a来看

 

（1）首先mobile打开浏览器，输入网站地址，这个动作会触发vpn连接（为什么vpn会连接？因为vpn隧道保护的是所有流量，所以vpn会自动启动）。浏览器从vpnprofile中获取pacfile url地址，然后去这个地址获取pacfile的内容。然后将要访问的网站地址和pacfile的内容进行匹配，如果匹配到了，就直接返回了proxy的地址。然后mobile将目的地址改成proxy的地址，也就是10.250.0.171.

源ip（10.32.145.136）-----目的ip（10.250.0.171）

（2）因为流量需要经过vpn隧道，所以数据包再进行封装，再源数据包的前面加上vpn隧道两端的ip地址，以及esp头部。封装之后为

新源ip（10.32.145.136）----新目的ip（10.250.70.11）----ESP----源ip（10.32.145.136）-----目的ip（10.250.0.171）

（3）当流量到达mvc之后，mvc解密并且解封装该流量，解封装之后数据包的格式为：

源ip（10.32.145.136）-----目的ip（10.250.0.171）

 

（4）然后进行数据包的重组，将数据包的源ip改成自己的出口ip（因为数据包的源ip是10.32.145.136，这是一个私网地址，对于prx来说它并不认识这个地址，所以需要将数据包的源ip进行更改），也就是10.250.70.111，目的地址依然是proxy的地址10.250.0.171，并且在http头部中加入x-ws-auth，像下面一样

（5）流量到达了prx之后，prx查看htttpget 头部，如果这个website跟web category里面的想匹配，并且action是deny，那么prx将会发送一个code200 forbidden给mvc，然后mvc通过vpn把网页内容传给mobile。

在prx上抓包tcpdump-i any port 443 or port 8081 or port 80 and host 10.250.70.111 -s 0 -w    *.cap

 

 

3.      Android Device

因为android设备的加密和解密都在android设备上完成的，所以数据包从mobile出来的时候没有外层的封装，并且该流量是明文的。

在fw抓包tcpdump-i any  host 10.32.145.159 -s 0 -wfw_ios_could_163.cap

10.32.145.159是mobile的地址

可以看到数据包没有被vpn封装。

并且数据包从mobile出来的时候已经打了x-ws-auth的认证消息，所以流量不会经过vpn，流量是直接到的prx，所以目的地址是10.250.0.171