企业远程办公如何打通内网？网络层隧道与封装直觉

专栏： 《计算机网络基础》

对应总览： 第四篇　网络层：让包跨越「很多个网络」

本篇角色： VPN / 隧道直觉------再包一层、路由怎么指进去、经典坑在哪

承接： 《NAT 专章》------共享公网出口解决「出得去」；本篇解决「安全地回到整段私网」

读完你能： 用「外层公网 + 内层私网」解释 VPN；看懂分流；定位 MTU/MSS 与握手失败的方向

导读：端口转发只开一扇小窗，VPN 开的是一条叠出来的路

连上公司 VPN 之后，访问内网 OA 仿佛「回到工位」。

上一章 NAT 让家里设备共享公网 IP；端口转发能把 某一个端口 露出来。

远程办公、跨云打通网段时，人们往往需要的不是「开一个 22」，而是：

我在咖啡店，却要像插在公司交换机上一样，访问整段 10.0.0.0/8。

公网并不会路由你家/公司的私网地址。办法是：在公网路上再垫一层「信封」------这就是隧道；外面常常再加加密与认证------产品名里就出现了 VPN。

复制代码

真实要发的包（内层）：  源=10.1.2.3 → 目的=10.9.9.9
叠上隧道之后（外层）：源=公网A   → 目的=公网B（VPN 对端）
                         载荷里塞着上面那只「内层包」

本篇是 直觉课，不是某厂商的配置手册：不堆点击路径，只把「叠包、指路由、MTU、分流、握手失败」讲到你能自己排方向。

一、概念：隧道与 VPN 各指什么？

1.1 隧道 = 再包一层

隧道（tunnel）：把本来要走的数据包（或帧）当作载荷，外面再套一层可在当前网络上传输的头。

生活类比：

复制代码

内层信封：寄给「公司档案室 10.9.9.9」
外层快递单：从「上海公网」寄到「北京公司网关公网」
快递只认外层；到了网关再拆开，按内层继续送

对中间互联网，它主要看见外层；对公司网络，解开后看见内层私网通信。

隧道可以：

只做封装（未必加密）
跑在 IP 之上（常见），有的更偏链路层语义

1.2 VPN：常是「隧道 + 认证 +（常常）加密」的产品说法

VPN（Virtual Private Network） 名字直译是「虚拟专用网」：在共享的公网之上， 逻辑上 呈现出专用网络的连通与隔离感。

概念级区分即可：

	含义
隧道	封装机制：怎么「再包一层」
加密/认证	外面的人看不懂、冒充不了（IPsec、TLS、Noise 等）
VPN 产品	把隧道、密钥、路由、客户端 UI 打包好的解决方案

没有加密的隧道在工程上存在（纯封装、某些数据中心内部），但你手机里连的「公司 VPN」通常 默认带加密------本专栏把它当成常见默认，不展开密码学细节。

务必分清两句话：

复制代码

隧道解决：私网包如何叠在公网上运输
加密解决：路上的人能不能看懂/篡改

「已连接但内网不通」常常是路由问题，不是「加密不够强」。

1.3 和 NAT 的关系（承接上一章）

复制代码

NAT：改写地址，让私网借用公网出口（会话表）
VPN：保留（或分配）私网地址语义，用隧道穿越公网把网段叠在一起

你在酒店连公司 VPN 时，往往同时经历：

酒店 Wi‑Fi 对你做 NAT（出网）
你的 VPN 客户端再把访问公司网段的流量封装进隧道
公司网关拆封装，按内网路由转发

两套机制叠罗汉------这也是隧道场景特别容易踩 MTU 的原因之一。

1.4 常见技术族（分类直觉，不背配置）

族	直觉	你可能在哪见到
IPsec	老牌、标准化味道浓；常与「站点到站点」网关配对	企业专线备份、防火墙 VPN
OpenVPN	常跑在用户态，TCP/UDP 灵活	老牌客户端生态
WireGuard	现代、配置面相对瘦，性能口碑好	部分商业产品底层
SSL VPN / 厂商客户端	体验偏「应用发布 / 门户」，底层仍是隧道思想	远程办公一键客户端
GRE / VXLAN 等	更偏「封装与叠加网」，加密另说	数据中心、云网络底层

记住一句就够：

名字不同，骨架多为：封装 +（可选）加密 + 路由指进去。

本篇不教某家客户端点哪里，只帮你建立排障语言。

1.5 远程接入 VPN vs 站点到站点：先分清你在哪一类故事里

	远程接入（Remote Access）	站点到站点（Site-to-Site）
典型用户	一台笔记本 / 手机	两个网关（机房↔云、总部↔分支）
地址感	客户端常获得虚拟 IP	两边网段互相宣告/静态指向
你常碰到	「连上公司 VPN」客户端	云控制台里的 IPsec 连接
排障入口	客户端日志 + 本机路由	网关状态 + 两侧路由表

两类都可以叫 VPN，但你问的问题不一样：

远程接入先问「我的 tun 起来了吗」；站点到站点先问「两边感兴趣流量（interested traffic）网段有没有配对称」。

二、原理：包如何「叠」上去，路由如何指进去？

2.1 封装位置的直觉

不必死记每个协议的字节图，先记住两种常见味道：

复制代码

A) 「IP 包外面再套 IP/UDP」------网络层附近叠包
   内层 IP 完整保留，外层负责在公网上找到对端
B) 「更偏安全关联 / 加密载荷」------如 IPsec 的一类形态
你仍可把它想成：私网包进了受保护的管道，管道两端是安全网关或主机

客户端连上后，系统里常多出一块虚拟网卡（tun0、wg0、ppp0 一类名字因实现而异）：

复制代码

应用 → 协议栈 → 目的匹配到「走 tun」→ 加密/封装 → 从真实网卡发到公网对端

2.2 路由如何指进隧道（这是 VPN「生效」的关键）

隧道建起来只是管道在；哪些目的地址走管道，仍由路由表决定------直接复用路由那章的最长前缀匹配。

复制代码

示例（示意）：
default via 192.168.1.1 dev wlan0           ← 普通上网仍走酒店网关
10.0.0.0/8  via 10.8.0.1 dev tun0          ← 公司网段指进隧道
172.16.0.5/32 via 10.8.0.1 dev tun0        ← 某主机路由

所以排障时两句最有用：

复制代码

1) 隧道接口是否 up？握手是否成功？
2) ip route get <公司内网IP> 是否指向 tun/wg 之类接口？

握手成功但路由没指进去------你「已连接」却访问不了内网，这太常见了。

2.3 全隧道 vs 分流（split tunnel）

模式	行为	直觉利弊
全隧道 / 全局隧道	默认路由也进 VPN	简单、出口统一；吃 VPN 带宽，断隧道等于几乎断网
分流（split tunnel）	仅私网段走 VPN，公网直连	看视频不绕公司；要精确维护「哪些前缀走隧道」

复制代码

全隧道：
  0.0.0.0/0 → tun0
分流：
10.0.0.0/8 → tun0
0.0.0.0/0 → 本地默认网关

分流配错的经典事故：漏了某段办公网前缀 → 「别的内网通，就这个系统不通」；或错误地把默认路由劫持 → 本地公网全挂。

反过来说：连上 VPN 后网站突然变慢，先确认是不是被全隧道绕去了公司出口。

2.4 MTU / MSS 黑洞：隧道最经典的坑

再包一层 = 外层头要占字节 。

若内层仍按 1500 去拼最大包，过隧道时可能：

需要分片（很多路径又讨厌分片）
或某跳丢弃「需要分片但 Don't Fragment」的包 → 大包不通、小包通

体感：

复制代码

ping 通、SSH 偶发卡死
HTTPS 卡在加载、小页面行大文件不行
scp/rsync 一传大块就停

这和 IPv4 专章里的 PMTU 黑洞是亲戚：隧道让「有效 MTU」更小，黑洞更容易出现。

TCP 场景常靠调 MSS clamp（中间设备或隧道接口提示两端用更小的段）缓解；ICMP「需要分片」被过滤时，排障更痛苦。

复制代码

排障直觉：
  先把测试包变小（ping -s），或临时降低隧道接口 MTU
  若小包立刻好、大包才坏 → 高度怀疑 MTU/MSS，而不是「账号没权限」

2.5 加密握手失败 vs 路由不对（别混着重启）

对排障来说要分成两类：

类型	典型症状	你该盯什么
握手/会话建不起	客户端一直 Connecting / 认证失败	端口可达、证书/密钥、时钟、账号策略
隧道已建但业务不通	显示 Connected，内网仍超时	路由、DNS、对端防火墙、MTU

加密放在哪一层（偏保护 IP 载荷，还是丢在 TLS 里）会影响抓包观感，但 先分层再动手 比先换客户端版本更有效。

2.6 DNS：连上了却「打不开内网名字」

很多工单不是 IP 不通，而是名字解析仍指向公网侧：

复制代码

连上 VPN 后：
  ping 10.0.5.20        → 通
  浏览器打开 oa.corp.local → 失败 / 解析到错误地址

常见原因包括：分流模式下 DNS 没走公司解析器；公司下发了 DNS 但操作系统没吃进去；分裂 DNS（内网名只用内网 DNS）与系统缓存打架。

所以 VPN 排障清单里应固定多一句：

先用 IP 证明隧道与路由，再用域名证明 DNS。

反过来说：只测域名失败，不足以证明「VPN 没连上」。

2.7 Keepalive、休眠与「早上起来 VPN 假死」

笔记本合盖休眠、酒店 Wi‑Fi 漫游、手机切蜂窝，外层五元组可能变掉。

隧道若依赖 NAT 会话或旧外层路径，会出现「界面还显示已连接，实际已经不能转发」。

工程上常见缓解是 keepalive / 重连策略 / 网络变化时重建会话。

对你而言，实用动作很朴素：先断开重连，再谈深挖；若重连必现，再按外层端口与 NAT 超时查。

三、应用：远程办公与跨云

3.1 远程办公：人在公网，地址却像在公司

复制代码

笔记本获得 VPN 虚拟地址 10.8.0.12
路由下发 10.0.0.0/8 → tun
访问 10.0.5.20:443 → 进隧道 → 公司网关 → 内网服务器

常见配套：公司防火墙只信任 VPN 地址段；没连 VPN 时公网直接打内网 IP 必然失败------这是策略，不是魔法。

3.2 站点到站点：两个机房/两个 VPC「拼」成一张大网

复制代码

VPC-A 10.1.0.0/16  ←隧道→  VPC-B 10.2.0.0/16
两边路由表互相指向对方网段的「下一跳 = 虚拟专用网关」

3.3 跨云与混合云

云厂商「VPN 连接 / 对等连接 / 专线」产品名各异，网络层直觉类似：

需求	更常落到
临时、加密、走互联网	IPsec/SSL/WireGuard 类 VPN
稳定、大带宽、低抖动	专线 / 私接（不一定叫 VPN）
同云不同 VPC	对等连接（可能不是传统 VPN 客户端）

选品是架构题；排障仍回到：外层是否通、内层路由是否指对、MTU 是否够。

3.4 不该期待 VPN 做什么

把公司 VPN 当成「网速加速器」------多数职场 VPN 反而更慢**。**

3.5 和「端口转发」怎么选（承接 NAT）

复制代码

只暴露一个 HTTP/SSH 端口给少数熟人 → 端口转发 / 反向代理可能够用
需要整段内网、多种协议、统一认证与审计 → VPN / 零信任接入更合适
临时演示、不想改家宽 → 内网穿透/中继类工具（本质也常是隧道）

没有绝对正确答案，但选错成本很具体：

用端口转发硬撑「全家桶内网访问」，规则会越堆越炸；

用全隧道 VPN 只为开一个端口，又会把无关流量拖进公司出口。

四、问题定位：VPN 坏了怎么拆？

4.1 先分层，别一上来重装客户端

复制代码

L0 账号/证书/时钟：认证材料过期、本机时间漂移
L1 外层可达：能否到达 VPN 服务器公网 IP/端口（被酒店防火墙拦 UDP 很常见）
L2 握手/会话：隧道是否 established（各客户端状态栏/日志）
L3 内层路由：ip route get 内网目标是否进 tun
L4 内网策略：公司防火墙/安全组是否放行 VPN 地址段
L5 路径质量：MTU/MSS、丢包、分流漏网段
L6 DNS：是否仍用公共 DNS 导致内网名字解析不到

4.2 握手失败：常见方向（不绑厂商按钮名）

方向	为什么会挂
外层端口不通	酒店/公司只放行 80/443；你的 VPN 用 UDP 51820 一类被丢
协议被中间盒干扰	某些网络对 UDP「长连接」不友好；有的方案可改 TCP/443（代价另说）
证书/预共享密钥	过期、拷错、两边配置不一致
身份与策略	账号有效但未授权该隧道/用户组
NAT 两侧行为	多重 NAT 下会话刷新、keepalive 间隔不合适导致「连上又掉」
时间同步	证书校验对时钟敏感

排查动作保持朴素：

复制代码

# 外层：网关公网是否达（ICMP 可能被禁，失败别一锤定音）
ping -c 3 vpn.example.com   # 或换成 IP
内层：连接成功后
ip -br addr          # 是否出现 tun0 / wg0 等
ip route             # 是否多了公司网段 / 默认是否被改
ip route get 10.0.0.5
ping -c 3 10.0.0.5   # 内网探测（若允许）

Windows 可对照：

复制代码

Get-NetRoute
Find-NetRoute -RemoteIPAddress 10.0.5.20
Test-NetConnection 10.0.5.20 -Port 443

抓包时分清：外层公网五元组 vs 内层私网地址------在错误的一层上看，会误判「没流量」。

4.3 故障速查表

现象	优先怀疑
一直连不上	外层端口/认证/时钟
显示已连接，内网全不通	路由未下发、分流漏前缀、虚拟网卡异常、DNS 未切
只有某个网段不通	缺那条更具体的路由或对端防火墙
网页转圈、大文件失败、SSH 怪异	MTU/MSS 黑洞
连上后公网也变慢或全断	全隧道拥塞或默认路由被劫持；公司出口故障
断断续续	休眠断会话、NAT 超时、无线不稳
分裂脑：有的站行有的不行	分流规则是否漏网段

五、动手：不配厂商手册，也能练会的直觉实验

不要在未授权网络上扫描端口或搭穿透；下面给出「只读观察」与「思想实验」两条路径。

实验 A：只读观察一次真实连接（有 VPN 的读者）

连接前：

复制代码

ip -br addr
ip route
ip route get 1.1.1.1
ip route get 10.0.0.1    # 换成你们真实内网地址

连接后原样再跑一遍，在纸上对比：

复制代码

1) 是否多了虚拟网卡与虚拟 IP？________
2) 是否多了指向公司网段的路由？________
3) 默认路由有没有被改掉？（全隧道 vs 分流）________
4) ip route get 内网IP 的 dev 是否变为 tun/wg/...？________

也可以把前后路由导出做 diff（Linux）：

复制代码

ip route > /tmp/route-before.txt
# 连接 VPN 后
ip route > /tmp/route-after.txt
diff -u /tmp/route-before.txt /tmp/route-after.txt

实验 B：分流线索------公网与内网各测一次

若公司允许：

复制代码

ping -c 3 10.0.5.20      # 内网
ping -c 3 1.1.1.1        # 公网
ip route get 10.0.5.20
ip route get 1.1.1.1

若两者 dev 不同，多半是分流；若公网也进了 tun，多半是全隧道。

实验 C：MTU 思想实验（或安全环境实测）

症状假设：小包 ping 通，业务大包卡死。

复制代码

# Linux 示意：调整包大小观察（需目标允许 ICMP）
ping -c 3 -s 1000 10.0.5.20
ping -c 3 -s 1400 10.0.5.20
ping -c 3 -M do -s 1400 10.0.5.20   # 部分环境禁止分片，更易暴露问题

若只有大包失败，去查隧道接口 MTU、是否启用 MSS clamp，而不是重装浏览器。

允许的环境里，也可把隧道 MTU 从 1420 逐步下调做对比。

实验 D：分流配置的纸面推演

假设表如下，判断访问目标会走哪条路：

复制代码

default via 192.168.1.1 dev wlan0
10.0.0.0/8 via 10.8.0.1 dev tun0

目标	走哪
`10.3.4.5`	隧道
`8.8.8.8`	本地默认
`10.3.4.5` 且误删 `/8` 路由	可能错误走默认 → 公网不可达该私网

用路由章的最长前缀匹配，VPN 场景立刻不神秘了。

六、网络层篇的收束，与下一层的接口

到这里，第四篇网络层主线可以收成一张短地图：

复制代码

IP：逻辑寻址
ICMP：报错与探测
路由：每一跳下一跳
NAT：公私网转换与会话
VPN/隧道：把私网语义叠在公网路径上

包终于知道「去哪台主机、出哪个口、要不要换地址、要不要进隧道」。

可它离开网卡之前，还得变成帧，在「下一跳邻居」之间交接------MAC、交换机、Wi‑Fi、ARP/ND，那是 链路层 / 物理层 的主场。

本篇知识地图

复制代码

隧道 = 内层私网包 + 外层公网可达封装
VPN ≈ 隧道 + 认证 +（常）加密的产品形态
生效关键：路由把目标前缀指进虚拟接口
分流 vs 全隧道决定「哪些流量进管」
经典坑：MTU/MSS、握手端口被拦、路由未下发
技术名（WireGuard/IPsec/OpenVPN...）先分类，不背手册
下篇方向：链路层------邻站交接

本章小结

复制代码

VPN/隧道把私网包叠进公网可运输的外层信封
加密与否是安全属性；路由指进隧道才是连通属性
全隧道与分流是路由策略选择，不是玄学开关
大包故障先想 MTU/MSS；连不上先想外层端口与认证
排障顺序：外层可达 → 握手 → 内层路由 → 对端策略 → 路径质量