pptp协议的工作原理
我的工作机是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服务器代理包的发送