在 IPv4 地址枯竭与云原生时代双重浪潮下，异地组网已从网络工程师的专属技能，演变为运维、开发乃至个人用户的共同需求。无论是跨国办公、物联网数据采集，还是云下 IDC 与云上 VPC 的互联，我们都面临同一个痛点：如何在复杂的 NAT 和动态 IP 环境下，建立一条可靠、安全且高效的虚拟链路？
本文按“穿透复杂度”由低到高，将方案分为三层路由互联、轻量 P2P 穿透、二层透明桥接、运营商级专用线路四大类，并拆解各自代表工具的适用边界。
扩展知识：运营商网络产品分类
从运营商拉的网络可分为三类：
① 普通宽带（家宽）：动态IP、共享带宽、上下行不对等
② 互联网/公网专线：固定公网IP、独享带宽、上下行对等
③ 专用线路（MPLS VPN / 裸光纤）：用于私网互联，全程不经过公网
三类线路的核心区别：①和②都连接公网，区别在于质量和IP是否固定；③不连接公网，用于私网互联。其中 MPLS VPN 走运营商 IP/MPLS 路由，裸光纤走光传输网（OTN/WDM）独立的波长调度体系。
第一类：三层路由互联—自建隧道（公网）
核心逻辑：在 IP 层（网络层）封装路由，两端通过协商或静态配置建立虚拟隧道，本质上是将隔离的路由表“拉直”。这类方案最成熟，但对底层 IP 地址的稳定性有不同容忍度。
两种隧道包结构对比
GRE 隧道：[ 新IP头 ] [ GRE头 ] [ 原始IP包 ]
IPsec 隧道：[ 新IP头 ] [ ESP头 ] [ 原始IP包 ] [ ESP尾 ]
GRE 像透明快递箱，箱外贴着"物品类型"标签，快递员一看就知道该送哪个仓库；IPsec 像密码保险箱，箱外什么都看不见，必须先跟收件人一对一电话对密码（IKE协商）才能开锁，因此无法同时发给一群人（组播）。
方案 A：裸跑 GRE 隧道（最轻量、最高效）
原理：GRE（通用路由封装）是一个协议号 47 的纯封装协议，它将任意三层协议（IPv4、IPv6、OSPF）打包进一个虚拟隧道接口。
固定公网IP场景：这是 GRE 最完美的“舒适区”。直接指定 tunnel source 和tunnel destination 为固定IP，隧道在 ip link set up 后瞬间建立，无握手开销，延迟极低。如果两端内网需要跑 OSPF 或 BGP 动态路由，GRE 是比 IPsec 更自然的选择（因为 IPsec 默认不支持组播）。
动态公网IP场景（非 NAT 环境）：若两端均为动态公网 IP（非 CGNAT），可借助 DDNS 将动态域名解析为当前 IP，配合脚本触发隧道重启。但若一端位于运营商级NAT（CGNAT）内网，DDNS 无效——因为 DDNS 拿到的是运营商NAT出口的共享 IP，无法映射到内网设备。
关键认知：GRE 是明文隧道，仅负责封装转发，不提供加密。在已有加密或物理安全的底层通道上，可叠加 GRE 来承载 OSPF 等组播协议（如 GRE over IPsec），无需额外加密；若 GRE 直接跑在公网上，则必须叠加 IPsec （见方案 B）或 WireGuard 保障数据传输安全。
方案 B：GRE over IPsec（加密 + 动态路由的“组合拳”）
原理：先用 StrongSwan 建立 IPsec 隧道（UDP 500/4500 或 ESP 协议），再将GRE 隧道跑在 IPsec 虚拟接口之上。这样既获得 IPsec 的强加密（AES-GCM），又保留了 GRE 承载组播协议的能力。
适用场景：数据需过公网且对安全合规有硬性要求，同时内网需运行动态路由协议。
注意：GRE 并非 StrongSwan 的默认配件，两者是独立协议，按需组合。如果只需点对点静态路由加密，直接用 StrongSwan 的 VTI（虚拟隧道接口）模式即可，无须引入 GRE 增加 MTU 开销。
配置要点：
# 1、搭建 GRE 隧道（方案 A）
# 2、配置 StrongSwan，保护 GRE 流量
# /etc/strongswan/ipsec.conf
type=transport # 用传输模式，非隧道模式
leftprotoport=gre # 保护 GRE 协议（协议号47）
rightprotoport=gre
# /etc/strongswan/ipsec.secrets
1.1.1.1 2.2.2.2 : PSK "你的共享密钥"
# 3、确认 SA 状态（GRE 是否被加密）
ipsec statusall # 确保状态为 ESTABLISHED方案 C：StrongSwan IPsec 直连（最省心的“安全快递”）
原理：基于 IKEv2 协议（适用前提：至少一端有固定公网 IP），两端协商加密参数，建立点对点 IPsec 隧道，数据面走 ESP 协议（IP 协议号 50）。另一端可为动态 IP 或位于 NAT 内网，需启用野蛮模式、NAT-T 及 MOBIKE 扩展。
绝对优势：配置标准化，加密算法经密码学界充分验证，支持证书和预共享密钥双认证。
短板：IPsec 协议栈仅处理单播流量，原生不支持组播/广播。ESP 头加密了整个内层载荷，解密前无法识别协议类型，且其安全关联（SA）依赖点到点的 IKE 协商，无法匹配“一对多”的组播模型——这是 IPsec 为加密安全而做的设计取舍，非技术缺陷。VTI 模式虽能强行导入组播包，但生产环境运行 OSPF 极不稳定，业界共识：动态路由场景请选方案 B。
VTI 配置示例：
# GRE 配置
ip link add gre-tun1 type gre local <本地IP> remote <对端IP>
# 纯 IPsec直连，VTI 模式：基于 StrongSwan + Linux VTI
# 1、配置 StrongSwan 先建立 IPsec 连接，配置 mark=100
# 2、创建 vti 虚拟网卡, 配置标签 okey/ikey=100
ip link add vti0 type vti local <本地IP> remote <对端IP> okey <出站标记> ikey <入站标记>
# 原理：发送时，进入这张网卡的包会被自动打上“100”标签，然后被 StrongSwan 捕获并加密发出；接收时，StrongSwan 解密的包会通过这个标签识别并交给这张网卡，然后由内核路由转发。补充：动态 IP 支持（一端固定公网 IP、一端 4G/CGNAT）
当一端有固定公网 IP（总部），另一端为 4G/5G 物联网卡且位于 CGNAT 内网时，GRE 隧道无法建立。此时可在同一 IPsec 框架下，将 4G 端配置为主动发起方：
使用 IKEv2 野蛮模式（避免依赖对端 IP 做身份标识）
开启 NAT-T（UDP 4500）（穿透 CGNAT）
启用 MOBIKE（4G IP重拨时自动重建隧道，无需人工干预）
效果：4G 端主动向总部公网 IP 发起连接，总部通过 NAT 建立的映射表“原路返回”数据，实现双向通信。这属于方案 C 的场景延伸，技术栈一致。
第二类：轻量级异地组网—解决无公网 IP、复杂 NAT 环境下的互联
核心逻辑：放弃对网络层的执念，改用 P2P 打洞（UDP/TCP 穿孔）+ 分布式节点（根服务器/中继） 的组合拳。只需联网，无需公网 IP，甚至无需专业网络知识。
常用工具对比
选型建议
裸 WireGuard：无“中间人协调”机制，要求通信双方至少有一方具备公网 IP。
私有化部署优先级：Headscale（基于 Tailscale） > ZeroTier（自建 Planet）/ EasyTier > Tinc
性能取舍：ZeroTier 基于二层封装，功能全面，但协议开销较大，速度和延迟逊于 Tailscale 的三层直连方案。
场景结论：对于远程桌面、文件传输、IP 直连游戏、内网服务访问等现代应用场景，Tailscale 综合体验优于 ZeroTier。
一句话总结：Tailscale 快，ZeroTier 全——现代场景选 Tailscale，老游戏/广播依赖选 ZeroTier。
第三类：二层透明桥接—自建隧道（公网）
核心逻辑：三层组网解决“通不通”，二层组网解决“像不像同一个交换机”。它把整个以太网帧（含MAC、广播、DHCP）搬到对端，让两地设备感觉插在同一台交换机上。
适用场景
三层路由（第一类）能满足 90% 的异地互通需求。只有遇到以下场景才需要二层：
虚拟机跨机房热迁移（IP 和 MAC 不能变）
遗留系统IP硬编码，无法改网段
依赖广播/组播的局域网应用（如打印机发现、特定工业协议）
方案组合：VXLAN + 底层穿透 + （可选）加密
异地二层桥接的典型技术组合是 VXLAN + 底层穿透手段 +（可选）IPsec。其中 VXLAN 负责二层帧的封装与解封装，底层穿透负责解决 VXLAN 无法跨越公网的问题，加密层负责保障公网上的数据传输安全。
VXLAN：也称为 VXLAN 隧道或 MAC-in-UDP 封装。原理是将二层帧封装在 UDP（端口 4789）中，两端各有一个 VTEP 负责封装/解封装。它天然绕过运营商对协议号 47 的限制，比 GRE 更适合跨公网传输。
底层前提：VXLAN 本身不解决公网穿透问题，它要求底层网络（Underlay）已可达 —— 要么两端已有专线，要么先通过 GRE/IPsec 或 SD-WAN 类方案（如 ZeroTier/Tailscale）把底层打通，再在之上跑 VXLAN。
加密层：VXLAN 本身是明文传输，若跑在公网上，建议叠加 IPsec 或 WireGuard 加密。
代价
MTU 降至 1450 以下
广播域扩大，易引发风暴
排障复杂度远高于三层方案
第四类：运营商级专用线路（不经过公网）
方案 A：MPLS VPN —— 运营商内网逻辑隔离，通过 MPLS 标签精确导向同标签匹配的对端私网。
方案 B：裸光纤 —— 物理层透明通道，走光传输网（OTN/WDM）独立的波长调度体系，不涉及 IP 路由。
两类专用线路的流量全程不经过公网，安全性与稳定性由运营商 SLA 保障。
选型决策树（最终总结）
你的两端是否有固定公网IP？
│
├─ 是 ── 是否需要动态路由协议（OSPF/BGP）？
│ │
│ ├─ 是 ── 是否要求强加密？
│ │ ├─ 是 → GRE over IPsec（StrongSwan做底层加密）
│ │ └─ 否 → 裸跑 GRE（性能最优，支持动态路由）
│ │
│ └─ 否 ── 是否需要加密？
│ ├─ 是 → StrongSwan IPsec VTI直连（配置最简）
│ └─ 否 → 裸跑 GRE（静态路由，轻量高效）
│
└─ 否（动态IP / 经过多层NAT / 移动端）
│
├─ 需要高性能、两端 NAT 类型友好 → WireGuard
├─ 需要跨平台、复杂 NAT 环境 → ZeroTier / Tailscale
└─ 极小规模技术验证 → Tinc（不推荐生产）四类方案一句话定位
排障铁律
异地组网最贵的不是带宽和服务器，而是排障时间。请遵循三条铁律：
1、分层验证：先 ping 通隧道两端的内网 IP，再测试业务端口。GRE/VXLAN 通不代表应用通，MTU 导致的丢包最隐蔽。
2、路由隔离：尽量避免大二层广播域跨越三跳以上，除非你的网络团队有专业运维能力。
3、加密适度：物理专线或云上 VPC 对等连接在网络连通性层面已天然隔离，裸跑 GRE/VXLAN 在网络连通性层面合规。但若业务涉及敏感数据（金融、医疗、政务），仍需叠加 IPsec 或 MACsec 加密以满足数据安全合规要求。
能用三层解决的问题，绝不拖到二层去烧脑；能用 UDP 打的洞，绝不靠 TCP 重传来折磨。
附录：常见商业组网产品的技术原理与自建可行性
1、花生壳（内网穿透）
本质：商业化的内网穿透服务，核心原理是反向代理 + 服务器中转，技术实现上与开源的 FRP 同源。
工作流程：
1、内网设备（或花生壳盒子）主动与花生壳云端服务器建立长连接隧道。
2、外网用户访问花生壳分配的公网域名或端口。
3、请求经由花生壳服务器，通过已建立的隧道转发至内网设备。
花生壳 vs. 自建 FRP
自建可行性：完全可行。 只需一台有公网 IP 的服务器部署 frps，内网设备运行 frpc，再配合开源 Web 管理面板（如 fpmgr）即可实现公司内部版的内网穿透服务。
2、蒲公英（异地组网）
本质：商业化的 SD-WAN 异地组网方案，核心技术是自研的 Cloud VPN + P2P 打洞 + 云端控制平面，与开源的 Headscale（Tailscale 控制面） 属于同类架构。
工作流程：
1、蒲公英设备（软件或硬件）启动后主动连接贝锐的云端控制器进行认证。
2、控制器下发组网策略（虚拟 IP、路由规则、访问权限）。
3、设备之间优先尝试 P2P 直连（UDP 打洞），失败时切换至云端中继转发。
4、形成虚拟局域网，实现多地设备“像在同一个交换机上”互访。
蒲公英 vs. 自建 Headscale + WireGuard
自建可行性：完全可行。 在公网服务器上部署 Headscale 作为控制平面，各分支机构使用 Tailscale 客户端接入，即可实现类似蒲公英的异地组网能力。若需硬件盒子，可采购廉价 ARM 开发板（如树莓派或国产 RK 系列），出厂预置 WireGuard 配置，实现“插电即入网”的体验。
3、那个“不用装软件的盒子”是怎么实现的？
无论是花生壳盒子还是蒲公英路由器，其“插电即用”的体验并非魔法，而是以下技术组合的产物：
1、硬件预制：设备出厂时烧录了唯一的设备编号（SN）和云端服务器的地址（如 https://xxx.oray.com），相当于内置了一个自动启动的客户端程序。
2、主动连接：设备通电联网后，根据预置地址主动发起连接到云端（而非等待云端连接内网），从而绕过 NAT 限制。
3、云端认证与策略下发：云端验证设备身份后，云端验证设备身份后，将用户预先配置的规则远程下发至设备，设备自动执行，无需人工配置。
4、即插即用——两种产品，两种路径
花生壳（内网穿透）：盒子主动与云端建立长连接隧道，外网请求由云端通过该隧道反向推送到盒子，再由盒子转发给内网目标。整个过程无需修改主路由任何配置，不涉及 ARP 代理。
蒲公英（异地组网）：盒子作为旁挂设备接入主路由 LAN 口后，需要将去往对端网络的流量“牵引”到盒子上，通过以下两种方式之一实现：
方式一：静态路由（需主路由配合）
在主路由上添加静态路由规则：去往对端网段的流量，下一跳指向蒲公英盒子的内网 IP。路径明确，可控性高，但需用户具备一定的网络配置能力。
方式二：ARP 代理（无需配置主路由）
蒲公英盒子开启 ARP 代理功能。当主路由广播询问对端 IP 的 MAC 地址时，盒子“抢答”并告知自己的 MAC，从而将流量引向自身，再通过 VPN 隧道转发至对端。无需修改主路由配置，用户无感，真正实现“即插即用”。
完成流量牵引后，终端设备正常上网，去往对端网络的流量会自动被盒子截获并转发，终端侧无需任何感知或配置。
附录：Linux ARP 代理配置示例
为特定IP添加代理条目，只响应该IP的ARP请求，不影响局域网其他设备通信：
# 代理单个 IP
arp -Ds 192.168.1.100 eth0 pub
# 验证是否生效
arp -n | grep 192.168.1.100
# 预期输出：192.168.1.100 ether xx:xx:xx:xx:xx:xx C M P A
# P 标志表示 Published（代理条目）
# 删除单条代理条目
arp -d 192.168.1.100参数说明：
-D：使用指定接口（eth0）的硬件地址
-s：添加静态ARP条目
eth0：响应该ARP请求时使用的网络接口
pub：表示这是一个发布的（Published）代理ARP条目
⚠️ 生产环境说明： ARP 代理配置中，代理的目标始终是VPN 对端网段（如 10.168.1.0/24），而非本地局域网网段，因此不会与本地设备产生 IP 冲突。若两端网段相同（如都是 192.168.1.0/24），需提前通过改网段或蒲公英地址转换功能解决。