时间：2021年7月21日
0x00 前言
Linux 环境，我本地测试环境使用的是 Ubuntu 18.04 x64。0x01 VPN是什么
vpn client 连接组织搭建的 vpn server 以建立通信隧道，随后便建立了虚拟的私人网络，处于外网的 worker 和内网中的 server 可以相互通信。VPN client 捕获用户发出的报文，封装报文后通过物理网络通信链路将报文发给 VPN server，VPN server 接收到报文后进行解包，再将其转发给实际的目标，反之同理；VPN 在逻辑层面构建了虚拟网络。0x02 TUN/TAP
# ip tuntap 创建名为 tun0 的 tun 设备sudo ip tuntap add dev tun0 mod tun# 为 tun0 配置 ipsudo ifconfig tun0 192.168.0.10 netmask 255.255.255.0# 查看 tun0 网卡ifconfig tun0
0x03 虚拟通信链路
simpletun 是这种方案的最小实现(源码仅 300+ 行，感兴趣的小伙伴可以自行学习)，在源码中实现了创建虚拟网络设备以及 socket 通信，借助 simpletun 可以帮助我们快速进行验证。simpletun 启动后需要我们手动配置虚拟网卡的 ip 地址，当 ip 地址未配置时，两端相互发送数据(部分操作系统会自动发送)会造成程序异常退出，所以在代码中添加一个 sleep(30) 便于我们配置 ip 地址：
Ubuntu 测试环境下配置并进行验证：# A主机# 编译 simpletungcc simpletun.c -Wall -o vpn# 作为 vpn server 启动，并开启 debug，默认监听 55555sudo ./vpn -i tun0 -s -d# 配置 tun 网卡地址sudo ifconfig tun0 192.168.0.10 netmask 255.255.255.0# B主机# 编译 simpletungcc simpletun.c -Wall -o vpn# 作为 vpn client 启动，连接 server，并开启 debugsudo ./vpn -i tun0 -c 10.11.33.50 -d# 配置 tun 网卡地址sudo ifconfig tun0 192.168.0.11 netmask 255.255.255.0
192.168.0.0/24 虚拟网络网段下，可以相互通信，如下：
0x04 访问内网网段
0x03 虚拟通信链路 的链路，VPN client 发送报文到内网主机，VPN server 接收到该报文后，将其写入到虚拟网卡中，随后报文进入 TCP/IP 协议栈，但是由于 IP 地址不是 VPN server 自己，该报文会被丢弃，无法正常进行通信；这里我们需要借助「报文转发」，将内网报文从虚拟网卡转发到内网网卡上。其新的工作流程如下：
VPN server 一般会作为内网网关，内网主机无需任何额外配置就可以在虚拟网段下正常工作。
0x03 虚拟通信链路 中的环境，在 VPN server 上我们使用 docker 模拟内网网段和主机，其环境搭建如下：
0x03 虚拟通信链路 中的方式，启动 simpletun 并使用 ifconfig 配置 ip 地址，创建虚拟通信链路；使用如下命令开启报文转发：# 临时开启报文转发echo "1" > /proc/sys/net/ipv4/ip_forward
实际上在该测试环境下，docker 会自动开启报文转发
iptables 配置转发策略，如下：# 将入口网卡、来源ip为 192.168.0.0/24 转发至 docker0sudo iptables -A FORWARD -i tun0 -s 192.168.0.0/24 -o docker0 -j ACCEPT# 将入口网卡、目的ip为 192.168.0.0/24 转发至 tun0sudo iptables -A FORWARD -i docker0 -d 192.168.0.0/24 -o tun0 -j ACCEPT
实际上在该测试环境下，第二条可以不用配置，因为 docker 会自动配置转发策略，会覆盖这条策略
# VPN client 添加内网网段路由，设置为虚拟网络设备 tun0sudo route add -net 172.17.0.0/24 tun0
0x05 拓 展
VPN server 一般作为网关进行配置，内网主机不用进行额外配置，也可以把报文发送给 VPN server。
在
simpletun 中 VPN server 和 client 之间使用 TCP 进行通信，但是在实际场景一般使用 UDP 进行通信。tcp in tcp，当出现丢包时，上层应用的 TCP 和 VPN 通信隧道的 TCP 都会进行重传，从而通信中出现大量的重传报文，降低通信效率；如果在这种情况下，以 UDP 作为通信隧道，tcp in udp，丢包后将只由上层应用的 TCP 进行重传。0x06 总 结
simpletun 创建了两端的虚拟通信链路，最后配合报文转发，实现并验证了 VPN 的通信工作原理。https://zh.wikipedia.org/wiki/%E8%99%9B%E6%93%AC%E7%A7%81%E4%BA%BA%E7%B6%B2%E8%B7%AF
https://zhaohuabing.com/post/2020-02-24-linux-taptun/
https://www.cnblogs.com/sparkdev/p/9262825.html
https://serverfault.com/questions/39307/linux-ip-forwarding-for-openvpn-correct-firewall-setup
https://liuyehcf.github.io/2019/08/25/OpenVPN-%E8%BD%AC%E8%BD%BD/
https://yunfwe.cn/2018/05/24/2018/%E4%B8%80%E8%B5%B7%E5%8A%A8%E6%89%8B%E5%86%99%E4%B8%80%E4%B8%AAVPN/
https://github.com/gregnietsky/simpletun
往 期 热 门
(点击图片跳转)
CVE-2021-33514：Netgear 多款交换机命令注入漏洞
赠书 |《404 Paper 精粹》第一期发布啦！
利用 Pocsuite3 框架编写 poc 实战案例
本文始发于微信公众号（Seebug漏洞平台）：VPN 原理以及实现
免责声明:文章中涉及的程序(方法)可能带有攻击性，仅供安全研究与教学之用，读者将其信息做其他用途，由读者承担全部法律及连带责任，本站不承担任何法律及连带责任；如有问题可邮件联系(建议使用企业邮箱或有效邮箱,避免邮件被拦截，联系方式见首页)，望知悉。
- 左青龙
- 微信扫一扫
-
- 右白虎
- 微信扫一扫
-
评论