4.1 VPN 概述与原理
4.1 VPN 概述与原理
本节摘要：SOURCE 4.1：VPN 五步骤——建立连接、身份验证、隧道、数据传输、断开。客户端流量经 VPN 服务器转发，加密防窃听。
故障场景：VPN 显示已连接但公网 IP 未变
可能是 split tunnel 仅路由内网段，公网仍走本地 ISP——并非故障，但用户误以为 VPN 无效。SOURCE 原理：全隧道时所有流量经 VPN 网关出去。
一、工作流程（SOURCE 4.1）
- 客户端向 VPN 服务器发起连接
- 身份验证（用户名密码、证书、MFA）
- 建立加密隧道
- 流量封装转发至目标
- 断开释放路由
二、与 TLS 关系（SOURCE intro）
OpenVPN 可用 TLS/SSL 做控制通道加密；TLS 保护单应用连接，VPN 保护 IP 层整包或隧道接口。
⚠️ 常见坑：公共 Wi-Fi 未开 VPN 时 DNS 泄露——即使后续 HTTPS 也可能被劫持引导。
💡 关键直觉：VPN 解决「链路层/网络层隐私与内网接入」，不是网站证书的替代品。
重点提炼
- 验证、隧道、路由三步缺一不可
- 全隧道 vs 分流策略要明确文档化
- 断开 VPN 应恢复默认路由
深入讨论：隧道、路由与 DNS 的三角关系
VPN 建连是否「成功」，与用户感知的「能不能访问」是两回事。隧道建立只是完成了加密通道，流量能不能到目标，取决于三层设置：路由表决定哪些网段走隧道，DNS 决定域名解析走哪个服务器，防火墙规则决定隧道内的包是否放行。「连上了却没流量」的工单，九成出在这三个环节之一。
全隧道模式把默认路由指向 VPN 网关，所有流量（包括 DNS）都进隧道，隐私性最好但会增加网关负载；分流模式只把内网网段送进隧道，公网流量仍走本地，体验好但存在 DNS 泄漏风险——本地解析器可能泄露用户访问了哪些域名。选型的本质是在隐私、性能与运维复杂度之间取平衡，并且要把选择明确写进文档，否则用户会误以为 VPN「没生效」。
# VPN 连接排障三步法 现象 排查项 验证手段 已连接但公网 IP 未变 路由模式 ip route 查默认路由走向 能连但解析不到内网域名 DNS 泄漏 / 解析器 dig 指定 VPN DNS 重查 隧道通但业务不通 防火墙 / ACL / 组策略 分网段 ping 与端口测试
排障时遵循「从底层往上」：先确认隧道层加密状态（接口有收发包），再查路由表是否命中，最后查 DNS 与业务层。每一步都有明确的验证命令，避免凭感觉重启客户端——这也是本节把五步流程拆出来的原因：把过程显式化，故障定位才有依据。
附录速查：VPN 隧道排障命令与路由模式对照
# 隧道层验证命令 ip link show # 查看虚拟隧道接口状态 ip address show tun0 # 查看隧道接口 IP ping -c 3 <vpn网关内网IP> # 验证隧道内连通性 traceroute <内网目标> # 观察路径是否走隧道 # 路由与 DNS 验证命令 ip route show # 查看默认路由是否指向 VPN ip route get <内网网段> # 查询特定目标的出口 resolvectl status / scutil --dns # 查看 DNS 服务器配置 dig @<vpn-dns> <内网域名> # 用 VPN DNS 强制解析 # 分流与全隧道模式对照 模式 路由行为 隐私 负载 适用 全隧道 默认路由走 VPN 高 网关大 隐私敏感 分流（内网） 仅内网段走 VPN 中 低 常规办公 分流（应用） 按进程/域名走 VPN 中 低 精准控制 # 常见「连上无流量」快速定位顺序 1. 隧道接口是否有收发包？否 -> 认证或协商失败 2. 路由是否命中目标网段？否 -> 分流配置或路由缺失 3. DNS 是否解析到内网？否 -> DNS 泄漏或解析器错误 4. 防火墙是否放行？否 -> ACL 或安全组限制
这套命令与定位顺序可以直接贴进排障手册。VPN 排障的最大误区是「连不上就重装客户端」，而实际上九成问题出在路由与 DNS 配置，先用命令把三层状态看清，再决定要不要动客户端。
补充一个安全视角：VPN 的加密强度再高，也替代不了接入后的访问控制。传统「连上 VPN 就等于内网人」的模型，让内网一旦被突破就横向畅通；因此现代实践倾向于把 VPN 只当作接入通道，配合按用户、设备与上下文的最小权限授权。本教程第 5 章的零信任部分正是这个思路的延伸——VPN 解决「能不能进来」，授权体系解决「进来后能碰什么」，两者职责不同，不能互相替代。
把「接入通道」与「访问控制」分开考虑，是 VPN 建设从及格走向成熟的分界点。