vpn分类(按照是否使用使用虚拟网卡通信来分类)
传统vpn,使用虚拟网卡通信
特点
使用vpn协议: OpenVPN、IPSec、L2TP/IPSec、WireGuard, 这些vpn通常会在本地生产一张独立的虚拟网卡,通过虚拟网卡来进行通信,如果需要抓包监听该vpn,可以直接使用wireshark监听该网卡实现抓包
- 这些VPN通常会在本地生成一张虚拟网卡（如TAP/TUN设备），用于处理加密流量。例如：
- TUN设备：处理IP层流量（路由模式，仅加密IP数据包）。
- TAP设备：处理以太网层流量（桥接模式，加密完整的以太网帧）。
- Windows示例：连接后可能在“网络连接”中看到名为“OpenVPN TAP-Windows Adapter”或类似名称的虚拟网卡。
- Linux/macOS示例：通过
ifconfig或ip addr命令可看到tun0或wg0等接口。
- 作用：
虚拟网卡将流量重定向到VPN客户端进行加密，再通过物理网卡发送到VPN服务器，实现隧道传输
OSI工作层级
- 工作层级：此类vpn的工作层级通常是网络层或数据链路层（OSI第3/2层，TCP/IP模型的“网络层”或“链路层”）。
- 典型协议：OpenVPN（TUN/TAP）、IPSec、L2TP、WireGuard。
- 特点：
- 全局流量接管：通过虚拟网卡（如
tun0）捕获所有系统流量（或按路由规则分流）。 - 修改系统路由表：强制将默认网关指向VPN接口，所有流量（除非例外）都经过加密隧道。
- 透明性：无需应用单独配置，所有应用自动走VPN。
- 更底层控制：可处理IP包或以太网帧（如TUN模式处理IP层，TAP模式处理链路层）。
- 全局流量接管：通过虚拟网卡（如
- 例子：商业VPN服务（NordVPN、ExpressVPN）、企业级VPN（Cisco AnyConnect）。
如何验证
- Windows：
打开“网络连接”面板，查看是否有新增的适配器（如“TAP-Windows Adapter”）。 - Linux/macOS：
运行ifconfig或ip link，寻找tun、tap、wg等前缀的接口。 - 通用方法：
使用VPN前后对比netstat -r或route print，观察默认网关是否指向VPN接口。
例外
部分代理软件v2ray/clash存在一个tun模式,会创建虚拟网卡（如 Clash TUN），接管所有流量（类似 VPN）。
开启全局代理后会强制所有流量走代理(包括dns)
确实是处理网络层的数据,但是是依赖应用层的代理协议来进行加密(例如socks5)
但是需要注意的是Tun模式对比传统vpn任然存在局限性:
- 不处理链路层数据（如 TAP）：
- 无法直接代理以太网帧（如企业 VPN 的局域网桥接需求）。
- 传统 VPN 的 TAP 模式可以做到这一点。
- 依赖用户态代理协议：
- TUN 本身不加密数据，依赖上层工具（如 Clash）通过 SOCKS5/Shadowsocks 加密，性能不如内核态 VPN（如 WireGuard）。
| 特性 | TUN 模式（Clash/V2Ray） | 传统 VPN（如 WireGuard） |
|---|---|---|
| 工作层级 | 网络层（IP 包） | 网络层（IP 包）或链路层（TAP 模式） |
| 是否加密 | ❌ 依赖上层代理协议（如 SOCKS5） | ✅ 原生加密（如 WireGuard 的 ChaCha20） |
| 流量覆盖范围 | 所有 IP 层流量（需配置路由规则） | 所有 IP 层流量（默认全局路由） |
| 性能开销 | 较高（代理协议+加密多层处理） | 较低（原生加密，内核态处理） |
| 典型用途 | 翻墙、分流代理 | 隐私保护、企业内网访问 |
代理型vpn,不使用独立的虚拟网卡
特点
- 用户态VPN（如部分移动端应用）：
某些轻量级VPN可能直接在应用层处理流量（如Android的VpnService API），无需内核级虚拟网卡，但仍会模拟一个虚拟网络接口 - 代理型VPN（如SOCKS5/HTTP代理）：
这类工具（如Shadowsocks）通常不创建虚拟网卡，而是通过本地代理端口（如127.0.0.1:1080）转发流量，仅影响配置了代理的应用程序。 - 从这里开始着重讨论的是代理型vpn
此类vpn不创建虚拟网卡,而是通过本地端口代理,而是完完全全的软件型,和传统vpn通过软件行为模拟硬件(创建虚拟网卡)不同的是,此类vpn并不尝试处理网卡需要处理的数据,而是直接处理应用层的数据(socks5/http)
工作层级
工作于应用层上,只对某个端口的流量进行转发,对更底层的数据不进行处理
需要注意的是,虽然socks5可以通过转发传输层（如TCP/UDP）的流量实现似乎可以处理任何通过tcp/udp传输的应用层数据(实际上是所用通过tcp/udp传输的数据),但是从具体的层级划分来说,socks5就是工作在应用层上的
socks5的工作范围
所有基于 TCP 的应用层协议：
- HTTP/HTTPS（网页浏览）
- FTP（文件传输）
- SMTP/POP3/IMAP（邮件协议）
- SSH（加密远程登录）
- RDP（远程桌面）
- 游戏（如 Minecraft、Steam）
- 各种 P2P 协议（BitTorrent）
所有基于 UDP 的应用层协议：
DNS（域名解析）
VoIP（如 Skype、Zoom）
QUIC（HTTP/3）
部分游戏（如 UDP 模式的在线射击游戏）
补充说明
- 代理的“伪下层”能力：
SOCKS5虽然属于应用层工具，但可以转发传输层（TCP/UDP）的流量，因此能代理游戏、P2P等非HTTP应用。而HTTP代理只能处理HTTP/HTTPS流量。 - VPN的灵活性：
现代VPN工具（如WireGuard）可以通过路由规则实现“分应用代理”（类似代理的灵活性），但底层仍需虚拟网卡支持。 - 性能差异：
代理型VPN通常开销更小（仅处理部分流量），而常规VPN因加密全流量可能对延迟更敏感。
socks5的局限性
尽管 SOCKS5 可以代理大多数应用层协议，但它仍然有 关键限制，使其无法完全替代 VPN：
无法代理非 TCP/UDP 流量
ICMP（Ping/Traceroute）：SOCKS5 无法代理 ICMP 协议，而 VPN 可以。
原始 IP 层流量（如 RAW Socket 通信）：某些低级网络工具（如
nmap的某些扫描模式）无法通过 SOCKS5 代理
依赖应用程序主动支持 SOCKS5
部分应用不支持 SOCKS5：
- 某些老旧软件（如 Windows 远程桌面 RDP 默认不走 SOCKS5）。
- 系统级服务（如 Windows Update、杀毒软件更新）通常不会走 SOCKS5。
需要手动配置：每个应用必须单独设置代理，而 VPN 是全局的。
无法修改 IP 层路由
- DNS 泄漏风险：即使 SOCKS5 代理了 TCP/UDP 流量，某些应用仍可能直接发送 DNS 请求（不走代理），导致隐私泄露。
- 无法强制所有流量走代理：VPN 可以修改路由表，强制所有流量走隧道，而 SOCKS5 只能代理配置过的应用。
无法处理链路层（L2）流量
- VPN（如 TAP 模式）可以代理完整的以太网帧（如某些企业 VPN 需要桥接局域网），而 SOCKS5 只能处理 TCP/UDP。
SOCKS5 vs. 常规 VPN 的核心区别
| 特性 | SOCKS5 代理 | 常规 VPN（如 OpenVPN/WireGuard） |
|---|---|---|
| 工作层级 | 会话层（代理 TCP/UDP） | 网络层（TUN）或链路层（TAP） |
| 代理范围 | 仅支持 SOCKS5 的应用 | 全系统流量（自动接管） |
| 是否依赖虚拟网卡 | ❌ 否 | ✅ 是 |
| 是否修改路由表 | ❌ 否 | ✅ 是 |
| 是否支持 ICMP/RAW | ❌ 否 | ✅ 是 |
| DNS 泄漏风险 | ⚠️ 可能泄漏（依赖应用配置） | ✅ 通常无泄漏（DNS 走隧道） |
| 适用场景 | 灵活代理（如仅浏览器/游戏） | 全局匿名/企业远程访问 |
对比dns泄露的问题
定义: 通过查询dns获取ip,但是由于可能对应的dns服务没有通过代理进行,从而导致监管者发现通信链(访问了哪个网站)从而导致的泄露
通过虚拟网卡通信的vpn对于所有的数据都会走虚拟网卡,包括dns请求也会走虚拟网卡,不会导致泄露
代理型vpn,有可能没有设置全局代理导致部分dns流量通过正常网络进行,而没有通过代理
- windows上的v2ray/clash等软件的全局代理(没有开启tun模式)的情况是通过修改
Internet 选项→连接→局域网设置来实现的,而这个只有http代理,所以一定会造成dns泄露 - 但是如果使用tun模式记忆库避免,但就变成了特殊的代理vpn,依赖代理协议进行加密,但是处理的数据实在传输层,不会造成dns泄露
- windows上的v2ray/clash等软件的全局代理(没有开启tun模式)的情况是通过修改
vpn协议
向大佬学习
大佬个人重新实现vpn: 南京大学 SSL VPN 协议分析与实现
在这篇文章中为了解密tls流量通过火绒剑找socket最多的的进程来发现实现vpn的进程,然后通过frida hook该进程(he0xwhale/ssl_logger: Decrypts and logs a process’s SSL traffic.)解密TLS流量
然后就可以查看vpn会话过程vpn情报信息搜集: VPN情报收集的常见方法与技术解析_YNXZ的技术博客_51CTO博客
不同vpn比较(有点ai味): VPN概述+VRF - 知乎
不同vpn的流量特征
| VPN 类型 | 默认端口 | 协议特征 |
|---|---|---|
| OpenVPN | UDP 1194 | TLS 握手 + Application Data |
| IPSec (IKEv1) | UDP 500/4500 | ISAKMP + ESP |
| WireGuard | UDP 51820 | 纯加密 UDP，无握手 |
| L2TP/IPSec | UDP 1701 + ESP | L2TP 控制消息 + ESP 加密 |
流量模式
- OpenVPN/IPSec：有明显的握手过程（Client Hello、IKE SA 协商）。
- WireGuard：无握手，仅小尺寸 UDP 包（加密数据 + Keepalive）。
- L2TP/IPSec：先有 L2TP 控制消息，后接 ESP 加密数据。
解密模式
- OpenVPN：若获取 TLS 密钥，可解密
Application Data。 - IPSec：需导入预共享密钥或证书解密 ESP 流量。
- WireGuard：几乎无法解密（无握手，静态密钥加密）。
VPN 流量的一般特征
无论哪种 VPN，在 Wireshark 中通常具有以下共同特点：
- 加密的载荷：原始数据（如 HTTP、DNS）被加密，无法直接解析内容。
- 固定的目标 IP/端口：VPN 流量通常指向固定的服务器 IP 和端口（如 OpenVPN 默认
1194/UDP）。 - 协议特征：不同 VPN 协议有独特的握手、保活机制，可在 Wireshark 中识别。
OpenVPN
- 使用默认端口udp 1194
- 使用TLS加密(类似HTTPS),流量显示为
TLSv1.2 / 1.3 - 握手阶段可见
Client Hello / Server Hello(未加密部分) - 数据传输阶段全部加密,显示为
Application Data
IPSec VPN
- 版本: IKEv1/IKEv2
- 阶段 1（IKE 协商）：
- 使用
UDP 500或UDP 4500（NAT-T）。 - 可看到
ISAKMP协议（IKE 协商包），包含 SA（安全关联）提议。
- 使用
- 阶段 2（ESP 加密）：
- 流量封装在
ESP(proto == 50)协议中，Wireshark 显示为Encrypted Payload。 - 除非导入预共享密钥/证书，否则无法解密。
- 流量封装在
WireGuard
- 端口: UDP 51820
- 使用 ChaCha20/Poly1305 加密，所有流量均加密。
- 无显式握手过程，仅定期发送
Keepalive包（短小的 UDP 包）。 - 在 Wireshark 中仅显示为
UDP流量，无协议标识。
L2TP/IPSec
- UDP 1701 + ESP
- L2TP 控制消息（未加密）：
- 使用
UDP 1701，可见L2TP协议头（如SCCRQ、SCCRP等控制消息）。
- 使用
- 数据部分：
- 实际数据通过
ESP加密，与 IPSec 相同。
- 实际数据通过
代理型vpn
| 特征 | OpenVPN (TLS Mode) | V2Ray (TLS + WebSocket/HTTP/VMess) |
|---|---|---|
| 协议基础 | 纯 TLS，类似 HTTPS | TLS 作为传输层，上层协议自定义（如 VMess、WebSocket） |
| 默认端口 | TCP/UDP 1194（常见） |
通常 TCP 443（伪装 HTTPS） |
| 握手特征 | 标准 TLS 握手（Client/Server Hello） | TLS 握手后，上层协议有独特特征（如 VMess 头部） |
| 数据包模式 | 持续加密流量，无额外协议头 | TLS 解密后可见 VMess/WebSocket 协议头 |
(1) JA3 指纹检测
- OpenVPN：JA3 指纹与普通 TLS 客户端不同（如自定义 OpenVPN 实现）。
- V2Ray：可能模仿浏览器 JA3 指纹（如 Chrome/Firefox）。
(2) 流量时序分析
- OpenVPN：流量较平稳（VPN 隧道保持活跃）。
- V2Ray：可能呈现 突发性（如 WebSocket 按需传输）。
(3) 解密 TLS（若可能）
- 使用 服务器私钥解密 TLS，直接观察上层协议：
- OpenVPN → 仍为加密 IP 包。
- V2Ray → 可见 VMess/WebSocket 协议头。
