我的工作机是A，通信网卡是Aeth0, Appp0；
然后我的云主机是B, 通信的网卡是Beth0, Bppp0；
在网卡Bppp0上会不断地很清晰的数据包：
16:40:39.522917 IP 61.135.169.121 > 192.168.0.234: ICMP echo reply, id 3361, seq 532, length 64
16:40:40.511096 IP 192.168.0.234 > 61.135.169.121: ICMP echo request, id 3361, seq 533, length 64 ①
16:40:40.523714 IP 61.135.169.121 > 192.168.0.234: ICMP echo reply, id 3361, seq 533, length 64 ②
16:40:41.512076 IP 192.168.0.234 > 61.135.169.121: ICMP echo request, id 3361, seq 534, length 64
16:40:41.524685 IP 61.135.169.121 > 192.168.0.234: ICMP echo reply, id 3361, seq 534, length 64
其中61.135.169.121是百度的ip地址，192.168.0.234 是我工作机A的IP地址，
在网卡Beth0上也会有清晰的数据包：下面是外界外界通信网卡Beth0上接收到的数据（去除了一些干扰的因素）；发现问题所在了吗？以16:40:40这次的ping操作为例来分析，总有的六条关键的浅蓝色数据。我们按照时间戳对这六条浅蓝色数据排序，发现的处理顺序是：③-①-④-⑤-②-⑥
梳理一下流程，对于VPN服务器来说，首先用Beth0网卡接收到了来自我工作机的请求，这个请求的上层协议是GREv1（通用路由封装 general routing encapsulation）协议，收到数据之后讲数据的内容传送给使用该协议发送数据的pptpd，pptpd完成一些简单的解密操作之后，将实际的数据内容（链路层+IP+ICMP），传送给ppp0，ppp0是一个tun设备，这个设备调用ppp驱动层层解压，到了IP层发现实际要达到的网络的IP地址是百度的61.135.169.121，于是是云主机内部进行了转发操作，于是我云主机的网卡就就把这个对百度的ping操作给转发了出去。。。。有没有肖申克救赎的既视感？怎么回来呢？spaceX发射后还是要回收的呢，回来这条path咋整？因为配置pptpd服务的时候我们配置了一条nat设置：iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -j MASQUERADE。这句话的意思是增加一条源是192.168.0.0/24的包机制，正好我们的从Beth0-->Bppp0-->Beth0出去的对百度的ping操作就是这样一个包，所以就这样，这个ping包换上我Beth0的主机地址真正地进入物联网大海了，然后baidu的主机61.135.169.121接收到了信息之后，百度的包回应了，回应之后数据到了我的云主机B，到了我的云主机后被网卡Beth0接收，接受好了之后，在路由之前IP地址被替换成了原来的地址192.168.0.234(iptables的设置有始有终呢)，然后这个数据包就开始在云主机B中路由了，在我的云主机B中，有这样一条路由信息：
192.168.0.234 * 255.255.255.255 UH 0 0 0 ppp0
意思是说发往192.168.0.234的包，通过ppp0走，好了就这样，这个包从ppp0出去啦。。。由于，由于，由于，重要的事情说三遍，由于ppp0是一个tun设备，所以用户态的pptpd可以直接把这个数据包读出来，读出来之后，把裸的IP+ICMP的数据包使用GREv1的数据包发送到我的工作机Aeth0卡上！顺利返回。有心的同学对照着我的大白话解释和这1-6条看看吧。肯定能一一对应上。大家可以自己理一下客户端的逻辑，我在本篇文章的最后会贴出客户端的逻辑，先自己分析。
16:40:39.510232 IP Aeth0 > Beth0: GREv1, call 384, seq 8535, length 101: compressed PPP data
16:40:39.510284 IP Beth0 > 61.135.169.121: ICMP echo request, id 3361, seq 532, length 64
16:40:39.522911 IP 61.135.169.121 > Beth0: ICMP echo reply, id 3361, seq 532, length 64
16:40:39.522956 IP Beth0> Aeth0: GREv1, call 37226, seq 8829, ack 8535, length 105: compressed PPP data
16:40:40.511062 IP Aeth0 > Beth0: GREv1, call 384, seq 8536, length 101: compressed PPP data ③
16:40:40.511103 IP > 61.135.169.121: ICMP echo request, id 3361, seq 533, length 64 ④
16:40:40.523707 IP 61.135.169.121 > Beth0: ICMP echo reply, id 3361, seq 533, length 64 ⑤
16:40:40.523753 IP Beth0 > Aeth0: GREv1, call 37226, seq 8830, ack 8536, length 105: compressed PPP data ⑥
16:40:41.512015 IP Aeth0 > Beth0: GREv1, call 384, seq 8537, length 101: compressed PPP data
16:40:41.512087 IP Beth0 > 61.135.169.121: ICMP echo request, id 3361, seq 534, length 64
16:40:41.524679 IP 61.135.169.121 > Beth0: ICMP echo reply, id 3361, seq 534, length 64
16:40:41.524732 IP Beth0 > Aeth0: GREv1, call 37226, seq 8831, ack 8537, length 105: compressed PPP data
配置好了pptp协议之后，用tcpdump抓Beth0和Bpp0上的包，在网卡B
客户端收发包的逻辑：
default * 0.0.0.0 U 0 0 0 ppp0
客户端的收发包，把对所有工作机A外的地址访问给给ppp0去转发，于是当我做了一个ping了百度61.135.169.121的操作之后，对与百度的ping的包会从ppp0发送出去，ppp0同样是一个tun设备，数据会被pptp的客户端监听到，客户端监听到之后，讲完整的这个数据包【ppp+ip+icmp]完整地打包，将目的地址设置成为云主机B的IP地址，作为数据由网卡Aeth0发出; 然后这个数据包就跑到了我的云主机B那边啦；
【这里有个疑问：我设置了链条default的路由，pptp客户端是怎么确定 default路由的信息的？抓下ppp0和eth0的包】
客户端收包，首先肯定是从外置的网卡中来的，然后包被客户端收到，客户端收到了包之后包被pptp的监听的进程收到，收到这个数据包之后，把数据包吸入ppp0接口，写入ppp0，由于ppp0就是一个本地的地址了，所以数据包就达到了目的地；以18:21:56的一次ping操作抓的数据包为例，仍然按照时间戳排序①-③-④-②
ppp0网卡抓包结果：
18:21:56.941225 IP 192.168.0.234 > 61.135.169.125: ICMP echo request, id 4332, seq 5, length 64 ①
18:21:56.970013 IP 61.135.169.125 > 192.168.0.234: ICMP echo reply, id 4332, seq 5, length 64 ②
18:21:57.943195 IP 192.168.0.234 > 61.135.169.125: ICMP echo request, id 4332, seq 6, length 64
18:21:57.972086 IP 61.135.169.125 > 192.168.0.234: ICMP echo reply, id 4332, seq 6, length 64
Aeth0网卡抓包结果：
18:21:56.941288 IP Aeth0 > Beth0: GREv1, call 384, seq 9804, ack 10012, length 105: compressed PPP data ③
18:21:56.969878 IP Beth0 > Aeth0: GREv1, call 19459, seq 10013, ack 9804, length 105: compressed PPP data ④
18:21:57.470673 IPAeth0 > Beth0: GREv1, call 384, ack 10013, no-payload, length 12
18:21:57.971982 IP Beth0 > Aeth0: GREv1, call 19459, seq 10014, ack 9805, length 105: compressed PPP data
整个过程中的疑问，当然都是小case啦
1）这里没必要做成ppp设备啊，普通的一个设备就好呢；
2）GRE协议在哪里起作用没发现
这两个问题慢慢看吧，不影响对VPN机制的理解啦！总之一句话，所谓的VPN，把包当做数据，pptp服务器处中转一下，pptp服务器代理包的发送