突发奇想

相信“阳康”的小伙伴居家办公的场景还历历在目，那VPN想必大家一定不会陌生，那不知道大家会不会有这么一个疑问，VPN服务端与客户端的流量传输是否真的安全的？那刚好我有一个朋友想知道连着公司VPN一边工作一边摸鱼会不会被发现？于是带着这个疑问开展了对于VPN服务端与客户端之间的流量传输的测试。

说干就干

此次模拟仿真服务为OpenVPN服务，核心技术是虚拟网卡和加密传输，OpenVPN是一个全特性的SSL VPN，它使用2层或3层的安全网络技术，标准的SSL/TLS协议，也是目前最接近商用VPN的开源解决方案。

仿真环境准备（局域网搭建环境）：

openvpn服务端IP：199.166.1.215

openvpn客户端IP：199.166.1.141

访问工作网站IP：http://199.166.1.202:7002

访问控制规则：禁止openvpn客户端到访问目标的流量

VPN客户端

1、客户端导入VPN认证证书，通过账户认证，连接VPN服务。此时客户端主机会创建一个虚拟网卡，依据配置文件分配虚拟网卡一个虚拟IP：10.8.0.6，那此时客户端主机将存在双网卡，一张主机物理网卡（en0）以及一张TUN虚拟网卡（utun3）。

ifconfigen0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
inet 199.1.1.141 netmask 0xffffff00 broadcast 199.1.1.255nd6 options=201<PERFORMNUD,DAD>media: autoselectstatus: activeutun3: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1500inet 10.8.0.6 --> 10.8.0.5 netmask 0xfffffffc

模拟工作时的场景，用户连接VPN，访问工作网站，通过wireshark分别抓取客户端主机物理网卡以及TUN虚拟网卡的流量，对流量包进行审计：

（1）主机物理网卡抓取流量中未发现本机直接访问工作网站的流量，说明访问目标网站的流量并未经过物理网卡直接进行传输，于是对虚拟网卡的流量进行审计。

（2）虚拟网卡中发发现虚拟IP与访问工作网站之间互相通信的流量，该流量为未经加密的明文流量，该部分流量包含了客户端发出流量以及工作网站返回流量，验证客户端流量会先经过虚拟网卡进行流量处理，再经由物理网卡进行实际网络环境内的流量传输；

（3）主机物理网卡中发现本机与VPN服务端之间的TCP以及OPENVPN协议流量，说明客户端与服务端之间经物理网卡传输的流量已经经过了VPN服务处理转变为加密流量在真实网络环境内进行传输；

经过对于客户端的流量抓取情况进行分析，可以得知在客户端层面，访问目标用户网站的流量调用虚拟网卡进行传输，在此过程中虚拟网卡收到并要转发出的流量为虚拟IP访问真实访问目标的流量，明确流量包的发送端和接受端后，VPN客户端会对流经虚拟网卡的流量进行加密再调用物理网卡进行实际网络环境内的流量传输。

VPN服务端

那对于服务端来说，服务端承担的角色是接受客户端的流量，将服务端作为请求发起方，向真实目标发送请求，由于服务端与访问目标之间不存在加解密协商过程，服务端转发流量应为正常的http/https请求，因此在这个流量转发的过程中一定涉及物理网卡接收客户端流量的解密。

通过tcpdump工具分别抓取客户端访问目标时间段内，服务端主机物理网卡以及TUN虚拟网卡的流量，利用wireshark对流量包进行审计：

[root@test ~]# tcpdump -i eth0 -s0 -w eth0.pcaptcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes16391 packets captured16394 packets received by filter0 packets dropped by kernel[root@test ~]# tcpdump -i tun0 -s0 -w tun0.pcaptcpdump: listening on tun0, link-type RAW (Raw IP), capture size 262144 bytes16063 packets captured16066 packets received by filter0 packets dropped by kernel

（1）服务端物理网卡接受到了客户端发送的加密传输流量；

（2）发现服务端虚拟网卡中存在虚拟IP与访问工作网站之间互相通信的流量，该流量同样为未经加密的明文流量，证实在服务端虚拟网卡存在加密流量解密，将明文流量通过物理网卡传输至真实访问目标；

（3）服务端物理网卡流量包抓取到服务端请求访问真实访问目标的明文传输流量，该流量经过对比与客户端wireshark抓取到的请求内容一致，证明服务端确实将客户端发送到请求进行代理转发，且对于访问目标来说，请求源为代理服务器的IP。

衍生问题

通过对客户端和服务端的网络流量包抓取分析可以看出，不论是客户端还是服务端流经虚拟网卡的请求流量，源IP均是10.8.0.6，但是实际环境中物理网卡并不能根据这个虚拟IP进行寻址，那么这里就会出现新的问题，服务端如何将请求返回包准确的返回给相应的客户端，虚拟网卡如何将虚拟网卡IP与真实客户端主机进行关联，并实现通知物理网卡完成准确的返回流量包分发？

OpenVPN服务端在虚拟网络环境内，本身承担了“路由器”的角色，在tap模式下按照mac地址路由，tun模式则按照ip地址路由，在此次试验环境中服务端配置为client-to-client，也就是tun模式，tun模式下路由项包含了客户端和服务端之间建立连接时两个TUN网卡之间的点对点路由，还包含了和VPN节点之外的目的网络通信而设置的系统路由。通过两项路由相结合的方式，告知对应的虚拟IP所映射的真实物理IP信息，再经过物理网卡实现真实网络环境内部的加密传输，因此本身TUN网卡技术不仅承担了流量加密传输的作用，同时也是作为软路由策略的关键承载，实现了通过软件更灵活的组网形式。

VPN流量传输过程总结

通过上述抓包的解析，大家可能还不能够直观的了解客户端的流量请求流程，图片是最容易说明逻辑问题的形式，如下图展示：

①用户端连接VPN客户端，客户端依据配置文件创建一张虚拟网卡，客户端所有进程的网络连接首先明文传输至虚拟网卡

②经过虚拟网卡的流量调用流量加密函数，对流量加密，传输至物理网卡

③物理网卡将经过加密的流量在真实网络环境内发送到VPN服务端的物理网卡

④物理网卡将接收到的加密流量传输至虚拟网卡，虚拟网卡调用流量解密函数对流量进行解密

⑤虚拟网卡将经过解密的明文流量进行代理转换传输至物理网卡

⑥物理网卡将发向访问目标的流量在真实网络环境内传输至真实访问目标

不忘本心

那么回到最初的问题，我朋友上班摸鱼的时候能不能够被公司抓到？抛开现实不同厂商VPN功能丰富程度不谈，在此次测试过程中朋友的摸鱼行为还是可以被审计到的，虽然在网络传输层OpenVPN将客户端与服务端端流量进行了加密，避免了中间人监听网络流量导致的信息失窃事件，但是无论是在客户端还是服务端，通过流量监听工具均可以监听到虚拟网卡中传输的明文流量，而在同一时间内服务端分配给客户端的虚拟IP为唯一的，通过虚拟IP的身份比对就可以抓到最终的摸鱼达人，当初摸鱼笑的有多大声，被发现处罚时就有多狼狈。

天马行空

本人主要参与网络安全运营工作，其中就涉及蜜网建设，测试完相关的技术就有了一些天马行空的想法——在网络安全攻防演练的过程中VPN可能是红队成员眼前一亮的线索，往年通过VPN直接攻破边界防护，如入无人之境的案例也皆有发生。

想象一下，假如说在信息搜集的过程中看到了靶标的VPN连接配置信息，那好像就是狼看到了羊，羊看到了草，那根本不可能忍住，好不好？

那换个角度想想，根据上述的测试，把真实的OpenVPN服务端换成带有流量监听的隔离蜜罐，当你尝试连接还连接成功，以为一举拿下兴高采烈准备写报告的时候，你的操作都被防守方看在眼里，想法全部暴露的时候，就好像在歌手决赛舞台上唱猪猪侠一样，一瞬间才发现小丑竟是我自己？！

心态比较好觉得被防守方抓到IP信息也没啥，反正是个人热点，挂了梯子，他们也猜不到我是谁，躲在电脑屏幕之后没有人知道是自己，自己不尴尬尴尬的就是别人。不过这还不是最恐怖的，最恐怖的是当你通过配置文件连接成功的时候，电脑或者自己的“肉只因”自己上线被溯源了？！当初到嘴的肥羊扭头发现是个披着羊皮的老虎，就问你刺激不刺激，具体的OpenVPN配置文件反制原理请阅读下面的文章，这里就不再赘述

https://www.freebuf.com/news/175862.html

题外话

网络安全最紧张刺激的环节就是攻防，在攻防的过程中不仅是技术能力的展现，也是内心深处的博弈，当你觉得你拿到了大门的钥匙，也有可能你步入了迷惑你的陷阱，行差踏错也就是一念间，黑客和白帽也只是一念之间，同一种技术黑客眼中是窃密，白帽眼中是御敌，而作为安全从业人员，更应该做的是守住内心一方清明，技术本身没有黑白是非，但是作为安全从业者应该有着自己的底线。