大二层组网技术详解：VXLAN、GRETAP 等

让两个相隔数百公里、只具备三层 IP 可达性的站点，看起来像插在同一台交换机上------这就是"大二层"最直观的效果。它解决了特定系统必须依赖广播、同网段地址或二层邻接的问题，也把广播风暴、环路、MAC 漂移和故障域一并带过了广域网。

先给结论

大二层不是"把路由关掉"，而是把完整 Ethernet frame 封装进可路由的外层报文，再在远端还原。
VXLAN 适合多租户、规模化和多站点，数据面是 UDP/VXLAN，EVPN 等控制平面是另一回事；VXLAN 本身不加密。
GRETAP 是 Linux 上很直接的点到点 Ethernet-over-GRE，配置少、内核数据路径清楚，但 GRE 是 IP protocol 47，不是"端口 47"，穿 NAT 往往不如 UDP 方案稳妥。
OpenVPN TAP 把二层与 TLS 型 VPN 集成在一起，适合少量桌面/服务器端点和跨公网场景；用户态处理、广播扩散及移动端不支持 TAP 是现实边界。
L2TPv3 是面向 Pseudowire 的二层承载，不等同于常见的 L2TP/IPsec 拨号 VPN；它既可直接使用 IP protocol 115，也可承载于 UDP，数据通道本身不提供密码学保护。
如果业务不依赖广播、非 IP 协议、固定同网段或透明二层邻接，优先做三层互联。广播域越大，故障爆炸半径通常越大。

图 0：大二层只要求 Underlay 能把隧道端点相互送达；业务主机看到的则是同一个逻辑广播域。

先把三个平面分开
[一帧 ARP 如何跨过 WAN](#一帧 ARP 如何跨过 WAN)
[VXLAN：规模化 Overlay 的主力](#VXLAN：规模化 Overlay 的主力)
[GRE 与 GRETAP：简单直接的点到点二层](#GRE 与 GRETAP：简单直接的点到点二层)
[OpenVPN TAP：把二层桥接放进加密 VPN](#OpenVPN TAP：把二层桥接放进加密 VPN)
[L2TPv3：以 Pseudowire 承载 Ethernet](#L2TPv3：以 Pseudowire 承载 Ethernet)
其他相关技术
[BUM、FDB 与规模边界](#BUM、FDB 与规模边界)
STP、环路与故障域
MTU：先明确从哪一层开始计算
[NAT、CGNAT 与防火墙](#NAT、CGNAT 与防火墙)
怎样给大二层加密
[四种重点方案的 Linux 实战](#四种重点方案的 Linux 实战)
性能、可用性与安全设计
对比表与选型决策树
分层抓包与排障
常见误区与不该使用大二层的场景

1. 先把三个平面分开

讨论大二层时，最容易犯的错误是把数据封装、控制平面和安全机制当成一个协议。工程上应先拆成三层：

维度	回答的问题	典型选择
数据平面	一帧 Ethernet 怎样跨三层网络？	VXLAN、GRETAP、L2TPv3、OpenVPN TAP
控制平面	远端 MAC、VTEP、成员关系怎样发现和撤销？	静态配置、数据面学习、组播、BGP EVPN、L2TPv3 控制连接
安全平面	谁能加入、报文是否保密、完整性如何保证？	IPsec ESP、OpenVPN TLS、WireGuard、ACL/PKI

1.1 "同一二层"究竟意味着什么

若 Host A 为 192.168.123.11/24，Host B 为 192.168.123.22/24，A 根据掩码判断 B 在本地链路，因此不会先把包交给默认网关。A 会发出 ARP Request，目的 MAC 为 FF:FF:FF:FF:FF:FF。只有当这个广播能够到达 B，且 B 的 ARP Reply 能返回，二者才会建立直接二层邻接。

所以大二层通常意味着：

两端处于同一逻辑广播域，广播、未知单播和相关组播可能跨站点扩散；
Bridge 根据源 MAC 学习入口，根据目的 MAC 查 FDB；
上层可以是 IPv4、IPv6，也可以是某些非 IP EtherType；
默认网关、VRRP/HSRP、DHCP、ARP、IPv6 ND 等协议可能同时被延伸；
Underlay 仍然是普通三层网络，只负责把外层隧道报文送到对端。

这与"两个站点使用相同的地址规划但彼此隔离"不同，也与普通三层 VPN 不同。前者没有二层互通，后者只传 IP packet，不会透明承载完整 Ethernet header。

1.2 点到点和多点是两类不同问题

两个站点之间只有一条逻辑线时，GRETAP 或静态 L2TPv3 很自然：所有未知流量只有一个远端可发。站点数上升后，拓扑、成员发现和 BUM 复制就成为核心问题。N 个站点做全互联点到点隧道，需要 N(N-1)/2 条隧道；一个入口广播在头端复制模式下还可能生成 N-1 份外层报文。

VXLAN 的优势不只是多了一个 VNI，而是它能够与组播或 EVPN 控制平面组合，建立规模化的多点 Overlay。反过来，一个只有两个固定端点的实验网络，并不会因为用了 VXLAN 就自动获得 EVPN 的能力。

2. 一帧 ARP 如何跨过 WAN

下面沿用统一示例：

Host A：IP 192.168.123.11，MAC 02:00:00:00:00:11；
Host B：IP 192.168.123.22，MAC 02:00:00:00:00:22；
VTEP-A：10.250.1.1；VTEP-B：10.250.2.1；
两个 Linux Bridge 分别连接本地 lan0 和隧道接口。

图 1：Underlay 只按外层隧道端点转发；业务 MAC 和原始 Ethernet frame 在远端解封装后重新进入 Bridge。

完整过程如下：

A 判断 192.168.123.22 属于本地 /24，发送广播 ARP Request。
站点 A 的 Bridge 从该帧的源地址学习 MAC-A → lan0。由于目的为广播，Bridge 将它复制到所有处于转发状态的相关端口，包括隧道口。
隧道端点在原帧之外添加 VXLAN/GRE/L2TPv3/OpenVPN 等外层头。WAN 路由器只依据外层 VTEP/Peer 地址转发；它不需要知道 192.168.123.0/24。
站点 B 的隧道端点剥掉外层头，把原始 Ethernet frame 注入 Bridge。Bridge 从入方向学习 MAC-A → tunnel，再把广播复制到本地 LAN。
B 返回单播 ARP Reply。站点 B 的 Bridge 学到 MAC-B → lan0，并依据刚学到的 MAC-A 把回复定向发往隧道。
A 端解封装后学到 MAC-B → tunnel。之后 A 与 B 的普通单播不再需要泛洪，直到 FDB 老化、拓扑变化或 MAC 移动。

这段流程揭示了两个关键事实：

隧道"通"不等于业务二层"通"。外层端点能 ping 通，只证明 Underlay 某些方向可达；Bridge 端口状态、FDB、ARP、VLAN、MTU 仍可能错误。
广播域的状态是分布式的。每个 Bridge/VTEP 都保存局部 MAC 位置，老化时间、丢包、单向链路和 MAC 漂移会使两端认知暂时不一致。

3. VXLAN：规模化 Overlay 的主力

VXLAN 由 RFC 7348 定义。它把内层 Ethernet frame 放入 8 字节 VXLAN header，再放入 UDP 和外层 IPv4/IPv6。VNI 字段为 24 bit，提供约 1600 万个标识的量级；具体可用值仍受实现和保留值约束。IANA 为 VXLAN 注册的默认 UDP 目的端口是 4789。VTEP（VXLAN Tunnel End Point）负责封装、解封装和 VNI 到本地二层实例的映射。

图 2：Underlay 只需路由可达和足够 MTU；VNI 123 属于上方的二层 Overlay，而不是 Underlay 的路由标签。

3.1 封装到底增加了什么

图 3：以外层 IPv4、无 VLAN、无 IP 选项为例，从内层 IP packet 口径计算，VXLAN 增加 50 字节。

典型报文从外到内为：

text 复制代码

Outer Ethernet | Outer IP | UDP | VXLAN | Inner Ethernet | Inner payload
                         8 B   8 B             14 B（无 VLAN）

VXLAN header 中 I 位表示 VNI 有效。原始 Ethernet 的前导码、SFD 和链路 FCS 不会作为 VXLAN 载荷跨隧道传送；每一段物理链路按自己的方式生成并校验链路 FCS。若存在 802.1Q/QinQ、外层 IPv6、IP 选项或安全封装，开销还会变化，不能把"50 字节"当成所有场景的固定答案。

Linux 内核的 VXLAN 文档特别建议显式指定 dstport 4789，以免历史默认值或不同实现造成互通偏差。检查接口时不要只看名字，应使用 ip -d link show 确认 VNI、本地/远端地址和目的端口。

3.2 FDB 学习和 BUM 复制

VXLAN 既需要知道"某个 MAC 在哪个本地端口"，也需要知道"远端 MAC 位于哪个 VTEP"。常见方式有三类：

数据面学习：VTEP 从收到报文的内层源 MAC 与外层源 VTEP IP 建立映射。实现简单，但未知目的和首次通信依赖泛洪。
组播分发：RFC 7348 的基础模型可为 VNI 绑定 Underlay 组播组，让 BUM 由组播树复制。它要求 Underlay 支持并正确运营组播。
EVPN 控制平面 ：BGP EVPN 通过 MAC/IP Advertisement、Inclusive Multicast Ethernet Tag 等路由发布 MAC/IP 和 BUM 成员信息，可配合入口复制或组播。RFC 8365 描述了 EVPN Overlay，RFC 7432 定义 EVPN 的核心路由机制。

图 4：未知 MAC 需要复制，已知 MAC 可定向送往单个 VTEP；EVPN 是可选控制平面，不是 VXLAN header 的一部分。

在静态头端复制场景，Linux 常用全零 MAC FDB 条目表示该 VXLAN 设备的泛洪目的列表，例如：

bash 复制代码

bridge fdb append 00:00:00:00:00:00 dev vxlan123 dst 10.250.2.1
bridge fdb append 00:00:00:00:00:00 dev vxlan123 dst 10.250.3.1

这不是"学到了 MAC 为全零的主机"，而是告诉内核把未知/广播流量复制到哪些远端。真实语法与对象可参考 bridge(8)。规模增大后，手工维护列表、撤销失效成员和处理 MAC 移动都会变得困难，控制平面的价值才真正显现。

3.3 VXLAN 的适用与边界

适合：

数据中心 Leaf-Spine、虚拟化、多租户网络；
需要大量逻辑二层实例或多点接入；
已有 EVPN/BGP、组播或集中式编排能力；
NIC/交换芯片能提供 VXLAN checksum、segmentation 等卸载。

不自动提供：

加密、对端身份认证和防重放；RFC 7348 也没有为 VXLAN 定义专用密码学保护；
MAC/IP 控制平面；仅创建 VXLAN 接口不等于部署 EVPN；
环路防护、广播限速或 MTU 修复；这些仍需独立设计。

4. GRE 与 GRETAP：简单直接的点到点二层

RFC 2784 定义 GRE 基础封装；外层 IP 的 Protocol/IPv6 Next Header 值为 47 。这里没有 TCP/UDP 端口。最小 GRE header 为 4 字节；RFC 2890 扩展的 Key、Sequence Number，以及可选 Checksum 等字段会继续增加开销。

Linux 的 gre 和 gretap 不是同一种接口语义：

gre 通常呈现为三层隧道接口，输入输出是 IP packet；
gretap 呈现为 Ethernet-like 接口，能够加入 Linux Bridge，典型 GRE Protocol Type 为 Transparent Ethernet Bridging 0x6558；
GRE Key 可用于区分逻辑隧道，但不是密码学密钥，不能提供认证或保密。

图 5：是否存在内层 Ethernet header，决定了接口能否作为二层端口加入 Bridge。

GRETAP 很适合两个固定、可直接 IP 到达的 Linux 端点：配置少，数据路径在内核中，抓包也直观。它的主要限制是原生点到点、没有控制平面、没有加密，而且 protocol 47 在 NAT、CGNAT 或只允许 TCP/UDP 的网络中经常不如 UDP 封装容易通过。

4.1 GRETAP 与 IPsec 的职责分工

若底层不可信，可以让 GRETAP 负责 Ethernet-over-GRE，让 IPsec ESP 负责认证、完整性、保密与防重放。ESP 是 IP protocol 50 ；遇到 NAT 时通常通过 NAT-T 封装为 UDP 4500。具体使用 transport mode 还是 tunnel mode，要看端点是否就是安全网关、地址策略、平台实现、NAT 和路由设计，不能一概而论。

图 6：GRETAP 的 GRE Key 只用于区分上下文；真正的锁位于外层 IPsec，而不是 GRE 本身。

Transport mode 通常直接保护 GRE 报文，可少一层额外隧道 IP header；Tunnel mode 则再加一组 IPsec 外层地址，常见于网关到网关。两者都要把 ESP、IV、padding、认证 tag 以及可能的 UDP NAT-T 计入 PMTU；ESP 开销不是一个固定常数，字段结构见 RFC 4303。

5. OpenVPN TAP：把二层桥接放进加密 VPN

OpenVPN 的 TUN/TAP 差别不是性能开关，而是承载层次：当前 OpenVPN 2.7 手册将 TUN 描述为三层 IPv4/IPv6 虚拟接口，将 TAP 描述为 Ethernet 802.3 虚拟接口。两端必须使用兼容的设备类型；TAP 只有加入 Bridge 后，才形成典型的跨站点二层桥接。

图 7：TUN 直接路由 IP；TAP 承载 Ethernet，并可桥接 LAN。只有右侧才延伸广播域。

5.1 为什么有人选择 TAP

OpenVPN 自带基于 TLS 的控制通道，并协商保护数据通道的密钥；封装与安全不必由两个独立产品拼接。
UDP/TCP 传输和客户端主动连接使它通常比裸 GRE 更容易穿过传统 NAT。
适合少量服务器、桌面或运维场景，需要临时承载广播发现、遗留协议或同网段地址。

5.2 TAP 的代价

用户态数据路径、加解密和每包复制通常比纯内核 GRETAP/L2TPv3 更吃 CPU；TCP 模式还可能出现"TCP over TCP"的重传耦合，数据隧道通常优先 UDP。
TAP 会把 ARP、IPv6 ND、DHCP 和未知单播带给远端客户端，接入数量增长后控制广播与隔离更困难。
当前 OpenVPN Connect 的 Android 与 iOS 客户端受系统 VPN API 限制，不支持 TAP。不能把"OpenVPN 跨平台"等同于"TAP 在所有平台可用"。
二层远程接入会让客户端更接近内网交换域；必须配置证书身份、最小权限、防火墙、客户端隔离和密钥撤销。

若只是让用户访问 IP 业务，TUN 几乎总是更清晰：路由边界明确，广播不跨 VPN，移动端兼容性也更好。

6. L2TPv3：以 Pseudowire 承载 Ethernet

L2TPv3 的设计目标是承载 Pseudowire，而不是把消费级"L2TP/IPsec 拨号 VPN"换个版本号。RFC 3931 定义 L2TPv3 的控制和数据协议；RFC 4719 定义 Ethernet over L2TPv3。一个 Ethernet Pseudowire 精确连接两个 Attachment Circuit，数据包携带完整 Ethernet frame，但不传前导码和 FCS。

图 8：Tunnel/控制连接可承载多个 Session；真正标识某条 Ethernet Pseudowire 的核心是 32-bit Session ID。

6.1 两种承载方式

直接 over IP ：外层 IP protocol 为 115。数据头包含 32-bit Session ID，并可携带 0、4 或 8 字节 Cookie；没有端口，因此通常比 UDP 模式更难穿 NAT。
over UDP ：控制连接初始目的端口使用注册的 UDP 1701，随后控制连接可以采用双方选择的端口对；数据报还包含 UDP header 以及 L2TPv3 的 flags/version/reserved 部分。静态 Linux unmanaged tunnel 也可以显式配置本地和远端 UDP 端口。

Cookie 用于增加错误投递或盲注入的难度，不等于密码学认证。L2TPv3 数据通道本身不提供机密性、完整性和对端身份保护；RFC 3931 明确讨论了使用 IPsec 保护两种承载方式。

6.2 Linux 的"静态 L2TPv3"没有替你做什么

Linux 内核的 L2TP 文档说明：内核负责数据路径，控制平面通常由用户态管理；ip l2tp 能创建静态、非托管 tunnel/session。它不会自动和远端协商 ID、Cookie、生命周期或故障恢复，双方参数必须人工镜像。以 l2tpeth 形式创建的会话接口才能加入 Bridge。

L2TPv3 适合需要明确 Pseudowire/Session 模型、设备间可互通且运营边界清楚的点到点场景。它不适合被误当成"天然安全 VPN"，也不应在没有 OAM、监控和重建机制时假设静态 session 会自愈。

7. 其他相关技术

7.1 EtherIP

RFC 3378 的 EtherIP 使用 IP protocol 97，头部只有 2 字节，概念极简。但该 RFC 是 Informational，明确指出协议没有环路保护，并建议新实现考虑标准化替代方案。它适合解释"最小 Ethernet-over-IP"思想，不是现代规模化 Overlay 的首选。

7.2 GENEVE

RFC 8926 定义 GENEVE，IANA 默认 UDP 目的端口为 6081。固定头为 8 字节，随后可携带可扩展 options；协议有意保持控制平面无关。它在需要元数据和可演进封装的虚拟化平台中很有价值，但 options 会让开销、硬件解析与互通测试更复杂。

7.3 EVPN 与 VPLS

EVPN 不是另一种隧道 header，而是一类 BGP 控制平面，可与 VXLAN、MPLS 等数据平面组合。它能发布 MAC/IP 可达性、BUM 成员、以太网段和多归属信息，减少纯数据面泛洪，并更好地处理 MAC 移动。

VPLS 则是运营商 MPLS/Pseudowire 语境下的多点二层 VPN。RFC 4761 描述 BGP 自动发现与信令，RFC 4762 描述 LDP 信令与 split-horizon 等行为。它依赖服务商/MPLS 核心能力，和在两台 Linux 主机间手工创建一个 GRETAP 不是同一运营模型。

7.4 ZeroTier

ZeroTier 官方将其网络描述为虚拟 Ethernet 网络，底层 VL1 对流量进行加密和认证，并由网络控制器签发成员凭据。它能通过 UDP hole punching 处理常见 NAT；严格/对称 NAT 或阻断 UDP 时可能退化到 relay，TCP relay 通常更慢。它适合追求"身份、控制器、NAT 穿透一体化"的覆盖网，但性能路径、控制器信任和成员授权方式与原生 Linux 隧道不同。可参考其协议说明、NAT/防火墙说明和 Relay 文档。

8. BUM、FDB 与规模边界

BUM 是 Broadcast、Unknown Unicast、Multicast 的合称。它们之所以重要，是因为交换机无法只向一个已知出口发送：

Broadcast：ARP Request、部分 DHCP 流程等；
Unknown Unicast：目的 MAC 尚未出现在 FDB，或对应条目已老化；
Multicast：没有有效 snooping/组成员状态时，可能被当成泛洪流量。

Linux Bridge 会从入站帧的源 MAC 学习 FDB 条目；动态条目经过 ageing 后删除。内核 Bridge 文档给出的 ageing_time 默认值为 300 秒，但设备、发行版和管理软件都可能改写，因此应以运行态为准：

bash 复制代码

bridge fdb show br br123
bridge fdb show dev vxlan123
ip -d link show br123
bridge -d link show

8.1 四种重点技术怎样处理 BUM

技术	典型 BUM 处理	规模影响
VXLAN	组播树、静态/动态头端复制、EVPN IMET 成员	可做多点；需控制复制和成员状态
GRETAP	点到点时直接送唯一远端；多点靠多条接口和 Bridge 复制	配置量与复制量快速增长
OpenVPN TAP	Server/Bridge 向相关 TAP 客户端复制，可按产品能力隔离	用户态加密与广播共同消耗 CPU/带宽
L2TPv3	每条 Ethernet PW 是点到点；多点业务由外部 Bridge/VPLS 组合	Session 与控制状态需要运营

8.2 抑制 BUM 的正确顺序

先确认业务是否真的必须共享广播域；能路由就不要延伸。
缩小每个 VNI/VLAN 的成员范围，不把"所有站点"当默认成员。
正确使用 IGMP/MLD snooping，但同时设计 querier；没有查询器时，组成员状态可能老化并退回泛洪。
在支持的 EVPN 实现中使用 MAC/IP 路由、ARP/ND suppression 等能力，并明确检查其学习来源和失效行为。
在边缘使用 storm-control/policer 限制广播、未知单播和组播速率；阈值应来自基线，而不是拍脑袋。
监控 MAC move、FDB 使用量、每 VNI BUM pps/bps，以及隧道复制后的 Underlay 实际带宽。

静态 FDB 能降低首次泛洪，却会引入陈旧状态风险。把 MAC 永久指向错误 VTEP 后，流量可能持续黑洞而不会靠老化恢复。因此静态条目只适合端点极稳定且有配置一致性检查的场景。

9. STP、环路与故障域

大二层最危险的问题不是"多几条广播"，而是让一个局部二层环路跨越高时延、低带宽 WAN。Broadcast 和 Unknown Unicast 没有 TTL，Bridge 会反复复制；源 MAC 从不同端口交替出现，形成 MAC flapping；CPU、隧道带宽和远端 LAN 可在很短时间内同时耗尽。

图 9：冗余二层路径如果没有统一的防环机制，就可能让一个站点的错误扩散到整个广播域。

9.1 STP 并不会因为存在隧道就自动生效

Linux Bridge 的 STP 默认是关闭的。可以在创建时启用：

bash 复制代码

ip link add br123 type bridge stp_state 1
ip link set dev br123 up

但"Bridge 开启 STP"仍不代表 BPDU 一定端到端到达：

设备可能在隧道入口消费、过滤或透传 01:80:C2:00:00:00 等 link-local MAC；
Linux Bridge 的 group forwarding mask、交换芯片、虚拟交换机和云网络策略都可能改变行为；
不同厂商的 STP/RSTP/MSTP 模式、region 配置和保护特性可能不兼容；
某些运营商 L2 服务会隧道传递 BPDU，另一些会终止或丢弃。

因此必须在两端抓包验证 BPDU，而不是从产品名推断。Linux Bridge 的具体属性和默认值可查阅内核 Bridge 文档。不要为了"让 BPDU 通过"就盲目放行所有 802.1D link-local 组地址；其中还包含 LLDP、LACP 等不同控制协议，错误透传会产生新的故障域。

9.2 防环应采用多层约束

拓扑约束：若无需冗余，每个广播域只保留一个明确的跨站点二层路径。
生成树 ：确需冗余时，统一设计根桥、路径开销、边缘端口和收敛模式；例如可提高 WAN 隧道口 cost，但要按实现验证：bridge link set dev vxlan123 cost 200。
边缘保护：面向终端的端口启用 BPDU Guard、Root Guard、loop guard 等设备能力；Linux 原生 Bridge 不能等价替代所有交换机保护功能。
广播限制：在靠近源头处实施 storm control，让故障在进入低带宽隧道前被限速。
VLAN/VNI 限界：只延伸必要 VLAN，避免把 native VLAN、管理 VLAN 或整个 trunk 无选择地桥接。
故障演练：主动断开一条 Underlay/Overlay 路径，观察 STP 状态、MAC flush、FDB 重新学习和业务恢复时间。

判断环路的常见证据包括：同一 MAC 在 lan0 与 tunnel port 间快速漂移；ARP/广播 pps 突增；Bridge CPU 飙升；多个站点同时出现间歇性丢包；同一帧在抓包中重复出现。此时应先隔离冗余路径和限制 BUM，再分析根因，而不是继续增加隧道重试。

10. MTU：先明确从哪一层开始计算

"VXLAN 开销 50 字节"和"VXLAN header 只有 8 字节"都可能正确，因为二者使用了不同口径。本文统一回答这个工程问题：Underlay IP path 能容纳的 packet，最多能承载多大的内层 IP packet？

若内层无 VLAN，计算式为：

text 复制代码

Inner-IP-MTU ≤ Underlay-PMTU
               − Outer-IP
               − Tunnel/Transport headers
               − Inner-Ethernet-header
               − Security overhead（若有）

图 10：先固定参考层，再按外层 IPv4/IPv6、VLAN、GRE options、L2TPv3 Cookie、IPsec 算法逐项增减。

10.1 常见最小开销表

数据面	外层 IPv4	外层 IPv6	计算假设
VXLAN	`20 + 8 + 8 + 14 = 50 B`	`40 + 8 + 8 + 14 = 70 B`	无内层 VLAN、无 IP 选项、无安全封装
GRETAP	`20 + 4 + 14 = 38 B`	`40 + 4 + 14 = 58 B`	最小 GRE header，无 options/安全封装
L2TPv3 over IP	`20 + N + 14 = 38--50 B`	`40 + N + 14 = 58--70 B`	RFC 4719 的 `N` 为 4--16 B，含 Session ID、可选 Cookie/L2-specific sublayer，不含 IP 与内层 Ethernet header
L2TPv3 over UDP	`20 + N + 14 = 50--62 B`	`40 + N + 14 = 70--82 B`	RFC 4719 的 `N` 为 16--28 B（含 UDP 相关封装），不含 IP 与内层 Ethernet header
OpenVPN TAP	可变	可变	取决于 UDP/TCP、数据通道协议、cipher/tag、packet-id、压缩策略等
上述封装再加 IPsec	继续增加	继续增加	ESP mode、算法 IV、padding、tag、外层 IP、NAT-T 均会影响

还要考虑：

内层每个 802.1Q tag 再增加 4 B；QinQ 通常再多一层 tag；
外层 IPv4 options、IPv6 extension header 会增加长度；
GRE checksum、key、sequence 等字段按实际组合增加；
L2TPv3 Cookie 可为 0/4/8 B，L2-specific sublayer 可为 0/4 B；RFC 4719 的 M+N 表示"封装后的外层 IP packet 比不含 preamble/FCS 的整个 Ethernet frame 多出的长度"。因此从内层 IP MTU 口径计算时，还必须另减内层 Ethernet header；
IPsec ESP 的 IV、padding 和 ICV/tag 与算法有关，Tunnel mode 还增加一组外层 IP；NAT-T 再增加 UDP 8 B。RFC 3948 定义 ESP-in-UDP 封装。

10.2 一个有条件成立的数值示例

假设 Underlay PMTU 确认是 1500，外层 IPv4、无 options、无内层 VLAN、无 IPsec，则 VXLAN 内层 IP MTU 上限是：

text 复制代码

1500 − 20 − 8 − 8 − 14 = 1450

这可以解释实验环境中的：

bash 复制代码

ip link set dev vxlan123 mtu 1450

但只要改用外层 IPv6、加入 VLAN、套 IPsec、经过 PPPoE，或路径中实际 PMTU 小于 1500，这个值就不再成立。正确做法是先测 PMTU，再依据实际报文或安全策略计算，并从内层业务端验证。

Linux IPv4 可用 DF 探测做二分查找。例如 -s 1372 加上 IPv4+ICMP 的 28 字节后，测试的是 1400 字节 IP packet：

bash 复制代码

ping -M do -s 1372 10.250.2.1
tracepath 10.250.2.1

这只是端点路径探测。还要在业务侧以相应内层 packet 大小验证隧道，观察 ICMP Packet Too Big/Fragmentation Needed 是否能返回。屏蔽这些 ICMP 会造成典型 PMTUD black hole：小包和 ping 正常，大包、TLS 握手或文件传输卡住。

TCP MSS clamping 只能调整 TCP SYN 中的 MSS，不能修复 ARP、UDP、ICMP、IPv6 ND 或任意非 IP Ethernet frame。因此它最多是针对特定 TCP 路径的缓解手段，不是大二层 MTU 设计。

11. NAT、CGNAT 与防火墙

NAT 是否友好，不能只看"有没有 UDP 端口"，还要看谁先发包、映射能否保持、对端地址是否稳定，以及返回流量是否命中同一映射。

方案	NAT 关注点	工程判断
VXLAN/UDP 4789	DNAT/SNAT、回程对称性、VTEP 地址与 NAT 后地址的映射、状态超时	可做，但"转发 4789"本身不足以自动解决端点发现和回程
GRETAP/GRE 47	没有端口；NAT 设备需理解 protocol 47 或建立明确的一对一映射	多租户/多会话和 CGNAT 下通常棘手
OpenVPN UDP/TCP	客户端主动建立会话；可配置 keepalive；服务端需要可达监听地址	传统客户端---服务端 NAT 场景通常最友好
L2TPv3 over IP 115	没有端口	RFC 3931 也指出相较 UDP 更不利于 NAT
L2TPv3 over UDP	可用明确端口对与状态映射	比 direct-IP 友好，但仍需 keepalive/生命周期设计
IPsec ESP	原生 ESP 50 无端口	检测 NAT 后常转 UDP 4500（NAT-T）
WireGuard	外层 UDP，常由内侧发起	可用 `PersistentKeepalive` 维持 NAT 映射，但不突破所有 CGNAT/防火墙
ZeroTier	UDP hole punching，必要时 relay	严格/对称 NAT 或 UDP 阻断可能导致中继与性能下降

11.1 上线前至少确认这些问题

两端是否拥有可路由公网地址，还是一端/两端位于 CGNAT？
NAT 映射是 endpoint-independent 还是对称映射？空闲超时多长？
防火墙允许的是 UDP/TCP 端口，还是也允许 IP protocol 47/50/115？
双向流量经过同一状态设备吗？多 WAN、ECMP、SD-WAN 切换后映射是否仍成立？
隧道配置中的 local/remote 应使用 NAT 前还是 NAT 后地址？外层策略和对端实际看到的源地址是否一致？
是否有 keepalive、Dead Peer Detection、重连和地址变化处理？

不要用"端口扫描能看到 UDP 4789"作为 VXLAN 成功证明。UDP 无连接，扫描结果本身含义有限；应该抓取有效封装报文、确认对端收到并解封装，再检查内层 ARP/FDB。

12. 怎样给大二层加密

四种重点方案中，只有 OpenVPN TAP 把密码学 VPN 与二层载荷直接集成。VXLAN、GRETAP、L2TPv3 都是封装技术，不应在不可信网络上裸奔。

方案	原生保密/认证	常见安全叠加
VXLAN	无	IPsec；或先建立 WireGuard，再让 VTEP 使用 WG 地址
GRETAP	无；GRE Key 不是安全密钥	IPsec；或在 WireGuard 地址间建立 GRETAP
OpenVPN TAP	有，依赖 TLS/证书及数据通道配置	通常无需再套一层 VPN，但仍需端点/Bridge ACL
L2TPv3	无；Cookie 不是密码学认证	IPsec ESP

12.1 VXLAN over IPsec

图 11：VXLAN 负责 VNI 和二层 Overlay；ESP 才负责加密、完整性与防重放，NAT 存在时可能再套 UDP 4500。

设计时要明确 IPsec 保护的 traffic selector：是两台 VTEP 间的 UDP 4789，还是整个站点前缀；是 host-to-host transport mode，还是 gateway-to-gateway tunnel mode。还要确保：

IKE 身份与授权绑定正确，不能只凭"知道对端 IP"放行；
XFRM policy 不会遗漏新 VNI/新端点，也不会把明文绕路放出；
重协商、anti-replay window、NAT-T 和多路径行为经过压力测试；
MTU 按实际 ESP transform 重新计算。

NAT-T 的 UDP 4500 同时可能承载 IKE 与 ESP-in-UDP；实现通过 Non-ESP Marker 等规则区分，细节见 IKEv2 RFC 7296 与 RFC 3948。运维抓包不能把所有 UDP 4500 都简单标成"加密业务数据"。

12.2 Overlay over WireGuard

WireGuard 官方将接口描述为三层隧道接口，传送 IP packet，并通过 UDP 加密传输。它不能直接承载 Ethernet frame；若要大二层，顺序应是：

先建立 WireGuard，获得两端可路由的 WG 地址；
让 VXLAN 或 GRETAP 的 local/remote 使用这些 WG 地址；
把 VXLAN/GRETAP 接口加入 Bridge。

图 12：Ethernet 先被 VXLAN/GRETAP 封装成 IP，再交给 WireGuard；不能把 Ethernet 直接写进 wg0。

这种组合配置直观，WireGuard 的 PersistentKeepalive 也可帮助维持 NAT 映射。但它是双层 Overlay：故障域、路由、MTU、监控和密钥轮换都要分别处理。多站点时，还要决定 WireGuard 是全互联、Hub-and-Spoke 还是由路由控制器管理，不能假设 VXLAN 会自动解决 WG 的可达性。

加密叠加不会让 NAT 问题消失，反而可能把原始 protocol 47/115 转换为 ESP，或在检测到 NAT 后再转换为 UDP 4500。回看上一节各封装的实际路径，应该以线上抓包看到的最外层协议配置防火墙和监控：

图 13：UDP 方案通常更容易建立映射；裸 GRE/L2TPv3-IP 没有端口，而 CGNAT 下用户通常无法配置入站映射。

12.3 L2TPv3 over IPsec

直接 IP 115 可用 ESP transport/tunnel 保护；UDP 模式也可通过 IPsec selector 保护相应端口。Cookie 仍应按用途配置，但不能替代 IPsec。若使用 NAT，通常还会看到 ESP-in-UDP/4500；此时总开销包含 L2TPv3、ESP、NAT-T 以及可能的额外外层 IP。

13. 四种重点方案的 Linux 实战

以下命令用于解释结构，不是可直接复制到生产的完整自动化。统一假设：

wan0 是 Underlay 接口，已能把隧道端点路由到对方；
lan0 是专用于实验的本地二层端口，没有承载当前管理连接；
两端业务 VLAN/untagged 语义一致；
每组命令只选择一种隧道，不要把全部接口同时加入同一 Bridge。

先在两端准备 Bridge：

bash 复制代码

ip link add br123 type bridge stp_state 1
ip link set dev br123 up
ip link set dev lan0 master br123
ip link set dev lan0 up

如果 lan0 原来持有三层 IP，通常应把该 IP 与相关路由迁移到 br123，不能让同一三层身份同时留在从接口和 Bridge 上。远程执行这一步可能立即切断管理连接，必须先有带外通道和原子回滚。

13.1 实验一：两点静态 VXLAN

站点 A：

bash 复制代码

ip link add vxlan123 type vxlan id 123 \
  local 10.250.1.1 remote 10.250.2.1 dev wan0 dstport 4789
ip link set dev vxlan123 master br123
ip link set dev vxlan123 up

站点 B：

bash 复制代码

ip link add vxlan123 type vxlan id 123 \
  local 10.250.2.1 remote 10.250.1.1 dev wan0 dstport 4789
ip link set dev vxlan123 master br123
ip link set dev vxlan123 up

若且仅若已经确认 Underlay PMTU=1500、外层 IPv4、无 VLAN/安全额外开销，可在两端演示设置内层 MTU 1450：

bash 复制代码

ip link set dev vxlan123 mtu 1450
ip link set dev br123 mtu 1450

这两条命令只设置本机 VXLAN/Bridge 的接口 MTU：Bridge 上的本机三层业务会受其影响，但它们不会自动修改接在 lan0 后面的外部主机 MTU，也不会通过纯二层 Bridge 神奇地"通知"所有终端。外部主机仍可能发出 1500 字节内层 IP packet，因此还需在终端、DHCP/RA、三层网关或 Underlay jumbo MTU 侧形成一致方案，并以业务端抓包验证。生产环境应按第 10 节重新计算。检查：

bash 复制代码

ip -d link show dev vxlan123
ip route get 10.250.2.1
bridge link show
bridge fdb show dev vxlan123

点到多点时，不要继续在 remote 参数上堆叠幻想；应选择组播、全零 FDB 头端复制列表或 EVPN，并设计成员撤销和 BUM 限制。

13.2 实验二：两点 GRETAP

站点 A：

bash 复制代码

ip link add gt123 type gretap \
  local 203.0.113.10 remote 198.51.100.20 ttl 64
ip link set dev gt123 master br123
ip link set dev gt123 up

站点 B：

bash 复制代码

ip link add gt123 type gretap \
  local 198.51.100.20 remote 203.0.113.10 ttl 64
ip link set dev gt123 master br123
ip link set dev gt123 up

在"Underlay PMTU=1500、外层 IPv4、最小 GRE、无 VLAN/IPsec"的限定条件下，内层 IP MTU 上限为 1500-38=1462。使用 GRE key 时，两端可加相同 key 参数以区分隧道上下文，但绝不能将其描述为加密密钥。

检查报文必须按 IP protocol 47，而不是端口：

bash 复制代码

tcpdump -ni wan0 'ip proto 47'
ip -d link show dev gt123
bridge fdb show dev gt123

如果要叠加 IPsec，应先完成 IKE/ESP 身份、算法、selector、NAT-T 和 MTU 设计，再让安全策略精确覆盖这对 GRE 端点。不要照抄只含预共享密钥的残缺配置到公网。

13.3 实验三：OpenVPN TAP 与 Linux Bridge

下面只是显示关键指令关系的配置片段 ，并非可运行的安全配置。证书链、私钥保护、tls-crypt/tls-auth、cipher negotiation、撤销列表、日志和权限必须根据当前 OpenVPN 2.7 文档补齐。

服务端片段：

conf 复制代码

port 1194
proto udp
dev tap0
server-bridge 192.168.123.1 255.255.255.0 192.168.123.200 192.168.123.220
keepalive 10 60
persist-key
persist-tun

客户端片段：

conf 复制代码

client
dev tap0
proto udp
remote vpn.example.com 1194
nobind
persist-key
persist-tun
remote-cert-tls server

服务端创建 tap0 后，将其和专用 LAN 口加入同一 Bridge；三层地址应配置在 br123：

bash 复制代码

ip link set dev tap0 master br123
ip link set dev tap0 up
bridge link show

server-bridge 地址池必须避免与现有 DHCP 池重叠。若已有物理 DHCP Server，需明确是让 DHCP 广播穿 TAP，还是由 OpenVPN 分配地址，防止两个服务器同时应答。还应决定客户端之间是否允许二层互访，不要因"加入同一 Bridge"无意扩大权限。

13.4 实验四：静态 L2TPv3 Ethernet Session

这里使用 direct-IP，因此外层为 protocol 115。站点 A：

bash 复制代码

ip l2tp add tunnel tunnel_id 100 peer_tunnel_id 200 \
  encap ip local 10.250.1.1 remote 10.250.2.1
ip l2tp add session tunnel_id 100 session_id 300 \
  peer_session_id 400 name l2tpeth123
ip link set dev l2tpeth123 master br123
ip link set dev l2tpeth123 up

站点 B 必须镜像 tunnel/session ID：

bash 复制代码

ip l2tp add tunnel tunnel_id 200 peer_tunnel_id 100 \
  encap ip local 10.250.2.1 remote 10.250.1.1
ip l2tp add session tunnel_id 200 session_id 400 \
  peer_session_id 300 name l2tpeth123
ip link set dev l2tpeth123 master br123
ip link set dev l2tpeth123 up

检查：

bash 复制代码

ip l2tp show tunnel
ip l2tp show session
ip -d link show dev l2tpeth123
tcpdump -ni wan0 'ip proto 115'

这是 unmanaged static tunnel，没有 L2TP 控制连接替你协商参数。若改成 encap udp，还要在两端显式、镜像配置 udp_sport/udp_dport，并在防火墙和 NAT 上放行实际端口；不能因为 IANA 注册了 UDP 1701 就假设任意静态 session 一定使用它。完整语法见 ip-l2tp(8)。

14. 性能、可用性与安全设计

14.1 不要只看"最高吞吐"

大二层的瓶颈可能出现在包速率、加密 CPU、单流、复制次数、重排或抖动，而不是链路带宽。建议至少记录：

64/128/512/1500 字节等不同 packet size 下的 pps 与吞吐；
单向与双向、单流与多流、TCP 与 UDP；
BUM 占比和头端复制后的 Underlay 实际字节数；
加密前后 CPU softirq、用户态 CPU、丢包、队列和 context switch；
延迟的 P50/P95/P99、jitter、reordering 与 failover 收敛时间；
长时间运行时的 FDB/邻居表增长、内存和密钥重协商抖动。

iperf3 能评估 IP 业务吞吐，却不会自动覆盖 ARP、广播、非 IP 帧和大量短包。应结合业务回放、包生成器、交换机计数器、ethtool -S、nstat、ip -s link 与抓包。

14.2 数据路径和卸载能力

技术	常见数据路径	可能的加速点	常见限制
VXLAN	Linux kernel / vSwitch / ASIC	UDP tunnel checksum、TSO/GSO/GRO、交换芯片 VTEP offload	NIC/驱动对端口与封装类型支持不一致；加密后可见性变化
GRETAP	Linux kernel	GRO/GSO、IPsec XFRM/crypto offload	某些 NAT/云防火墙不支持 GRE；多点复制靠 Bridge
OpenVPN TAP	主要为用户态加解密与 TAP I/O	多队列、密码指令集、合理 cipher；能力随版本/平台变化	TAP 与某些内核数据通道加速并不兼容；每包用户态成本明显
L2TPv3	Linux kernel 数据路径，用户态控制/编排	checksum/segmentation、硬件 PW 能力（依平台）	静态 session 缺少自动协商与自愈；互通参数多

查看 NIC 是否声明 UDP tunnel offload：

bash 复制代码

ethtool -k wan0
ethtool --show-tunnels wan0
ip -s link show dev wan0
ip -s link show dev vxlan123

"显示支持"不等于当前数据流一定命中硬件路径。应对比 CPU、接口计数器与真实吞吐，并检查自定义 VXLAN 端口是否已经注册给 NIC。小包场景通常先撞上 pps/CPU，大包场景更容易暴露 MTU、分段和 checksum offload 问题。

14.3 可用性不是多建一条隧道

冗余 Underlay、冗余 Tunnel Endpoint 和冗余二层路径属于不同层：

Underlay ECMP 可能在不改变 Overlay 状态的情况下绕开故障；
两个 VTEP/网关需要解决 anycast、MAC ownership、状态同步或 EVPN multi-homing；
两条并行二层隧道会形成环路，必须由 STP、EVPN split-horizon/DF election 或受控链路聚合处理；
keepalive 只检测某层对端活性，不能证明远端 Bridge、LAN 或业务主机可用；
故障切换后要验证 FDB flush/MAC move、ARP/ND 更新和上游安全策略。

生产验收应至少演练：断 WAN、断单个 VTEP、重启 Bridge、重协商 IPsec、NAT 映射重建、MAC 移动、MTU 黑洞和广播突发。

14.4 安全威胁模型

大二层会把攻击面从"可路由 IP 服务"扩大到整个二层控制面。应显式考虑：

伪造/注入：伪造源 MAC、ARP/ND、DHCP、RA、BPDU，导致中间人、错误网关或拓扑改变；
窃听：VXLAN/GRE/L2TPv3 明文可被路径观察者读取；
重放：裸封装没有统一 anti-replay；GRE sequence 也不能替代密码学防重放；
资源耗尽：随机源 MAC 撑满 FDB，BUM 风暴耗尽低带宽 WAN，碎片重组消耗端点资源；
横向移动：远端 TAP/站点一旦被桥接，可能直接触达原本只在本地 LAN 出现的服务；
控制平面劫持：EVPN/BGP、VPN 控制器、PKI 或编排凭据失陷会批量影响多个二层实例。

对应措施包括：在不可信 Underlay 上使用经过认证的加密；最小化 VNI/VLAN 成员；入口 anti-spoofing、DHCP snooping/DAI/RA Guard（按设备能力）；限制每端口 MAC 数、BUM 速率与 MTU；控制平面使用明确邻居、PKI和最小权限；对 MAC move、异常 ARP、BPDU、解密失败和重放计数告警。

安全策略要落在实际最外层：例如 VXLAN over IPsec 在 WAN 上可能只看到 ESP 或 UDP 4500，而在解密后 XFRM 路径上才能看到 UDP 4789。只监控其中一层会留下盲区。

15. 对比表与选型决策树

15.1 四种重点方案工程对比

维度	VXLAN	GRETAP	OpenVPN TAP	L2TPv3 Ethernet PW
内层载荷	Ethernet frame	Ethernet frame	Ethernet 802.3 frame	Ethernet frame（RFC 4719）
外层标识	UDP dst 4789，24-bit VNI	IP proto 47，GRE type 0x6558；可选 key	可配 UDP/TCP，IANA 注册 1194；实际端口可改	IP proto 115，或 UDP；32-bit Session ID，Cookie 0/4/8 B
典型拓扑	点到点、多点、多租户	原生点到点；多点靠多接口/Bridge	客户端---服务端/Hub	每条 PW 点到点；Tunnel 可承载多 Session
控制平面	静态、数据面学习、组播、EVPN	通常静态	OpenVPN TLS 控制通道/服务端配置	L2TPv3 控制连接或 Linux 静态 unmanaged
BUM	组播或头端复制；EVPN 管成员	送唯一远端；多隧道时 Bridge 复制	Server/Bridge 复制到 TAP 端点	由外部 Bridge/PW 组合复制
原生加密	否	否	是，取决于 TLS/数据通道配置	否
常见加密组合	IPsec，或 VXLAN over WireGuard	IPsec，或 GRETAP over WireGuard	通常不再叠加；仍需二层 ACL	IPsec
NAT 适应性	UDP 可映射，但静态 VTEP/回程需设计	较差；proto 47 无端口	较好；客户端主动连接	UDP 模式较 direct-IP 好
最小/范围 IPv4 开销口径	50 B（含内层 Ethernet）	38 B（含内层 Ethernet）	可变	从内层 IP 口径：direct IP 为 38--50 B；UDP 为 50--62 B（均含 14 B 内层 Ethernet）
实现路径	内核/vSwitch/ASIC 广泛支持	Linux kernel 简洁	用户态为主	Linux kernel data path；运营设备常见 PW
多租户隔离	VNI 空间大，生态成熟	key/接口可区分，编排弱	每实例/证书/Bridge 策略	Session/PW 模型清晰
主要优势	规模、生态、EVPN/硬件协同	简单、低开销、易抓包	加密与接入整合、UDP/TCP 穿透	明确的 PW/Session 与设备互通模型
主要短板	本身不加密；BUM/控制面/MTU复杂	NAT、无加密、原生点到点	TAP 平台限制、用户态成本、广播面大	本身不加密；静态 Linux 模式无自动协商
最适合	数据中心、多站点、VNI/EVPN	两个稳定 Linux 端点	少量桌面/服务器的安全二层接入	运营商式点到点 Ethernet PW、设备互联

表中的开销不能横向直接当成性能排名：OpenVPN/IPsec 的密码算法、硬件卸载，VXLAN 的 NIC offload，BUM 数量和 packet size 往往比几十字节差异更重要。

15.2 扩展方案定位

方案	定位	何时考虑	关键提醒
GENEVE	可扩展 UDP Overlay header	平台需要携带可演进元数据	UDP 6081；options 增加解析/MTU复杂度
EtherIP	极简 Ethernet-over-IP	遗留互通或研究	proto 97、2 B header、无环路保护
EVPN	BGP 控制平面	多站点 MAC/IP 分发、多归属、抑制泛洪	必须和具体数据面/实现一起设计
VPLS	MPLS/PW 多点 L2VPN	已有运营商/MPLS 核心	依赖 BGP/LDP 信令与 PE 运营能力
ZeroTier	身份化加密虚拟 Ethernet Overlay	希望集成控制器、成员授权与 NAT 穿透	中继路径性能、控制器信任和授权需评估

15.3 决策树

图 14：第一问不是"选哪种隧道"，而是业务是否真的需要二层；不需要时，应优先停在三层。

可把选型收敛为以下顺序：

必须是二层吗？ 若只是 IP 可达、服务发现或地址迁移问题，优先路由、DNS/注册中心、应用层复制、L3 VPN。
有几个站点、是否持续增长？ 两个固定 Linux 端点可优先 GRETAP/L2TPv3；多点、多租户、动态 MAC 需要 VXLAN，并在规模上升时引入 EVPN。
Underlay 是否可信？ 不可信时，VXLAN/GRETAP/L2TPv3 必须叠加 IPsec/WireGuard；若少量客户端且需要集成 VPN，可考虑 OpenVPN TAP。
NAT/CGNAT 情况怎样？ 客户端主动发起的 OpenVPN/WireGuard/ZeroTier 通常更易处理；裸 protocol 47/115 要求可控网络或一对一映射。
平台是否支持 TAP？ iOS/Android 的 OpenVPN Connect 不支持 TAP；移动用户应改为 TUN/L3 设计。
是否已有控制平面和硬件能力？ 已有 EVPN/VXLAN fabric 时不要另造静态全互联；只有两台 Linux 时也不必为"高级"而强上 BGP。
谁负责广播、环路、MTU和故障？ 如果团队不能监控 BUM/FDB/STP/PMTU，就不应把广播域跨越不可控 WAN。

几个典型答案：

两台有固定公网/专线地址的 Linux 网关、只延伸一个 VLAN：GRETAP 简洁；公网不可信时再用 IPsec。
三个以上数据中心、VLAN/VNI 较多、需要多归属和 MAC 移动：VXLAN + EVPN，更符合长期运维。
少量 Windows/Linux 运维端需要加入遗留广播域且跨 NAT：OpenVPN TAP 可行，但先确认平台与广播隔离；普通访问优先 TUN。
运营设备间交付明确的点到点 Ethernet PW：L2TPv3；公网承载时配 IPsec，管理 Session/OAM。
双方都在严格 CGNAT 且无法控制入口：不要先选裸 GRE/L2TPv3-IP；考虑有协调/中继能力的 Overlay，或购买可控公网/专线服务。

16. 分层抓包与排障

排障应从外到内，每一步只回答一个问题。最忌讳看到端点 ping 成功就开始修改业务主机。

图 15：按 Underlay → 外层封装 → 接收/解封装 → Bridge/FDB → ARP → MTU/安全/NAT 的顺序收敛。

16.1 第 1 层：Underlay 与策略

bash 复制代码

ip addr show dev wan0
ip route get 10.250.2.1
ping -c 3 10.250.2.1
tracepath 10.250.2.1

确认实际选中的源地址、下一跳、接口和 PMTU。多路由表/VRF/策略路由环境要带上相应 namespace/VRF 测试。Ping 失败不一定证明隧道必败（对端可屏蔽 ICMP），但 route lookup 错误一定应先修。

16.2 第 2 层：最外层报文是否发出和到达

使用可移植的 pcap filter：

bash 复制代码

# VXLAN
tcpdump -ni wan0 'udp dst port 4789'

# GRE / GRETAP
tcpdump -ni wan0 'ip proto 47'

# L2TPv3 direct-IP 或 UDP 控制/承载
tcpdump -ni wan0 'ip proto 115 or udp port 1701'

# IPsec ESP 或 NAT-T
tcpdump -ni wan0 'esp or udp port 4500'

在 A、B 两端同时抓包并产生一帧明确的 ARP。若 A 发出而 B 收不到，检查中间 ACL、NAT、路由、外层 TTL、对称性和云安全组；若 B 收到但没有解封装，检查 local/remote、VNI、端口、GRE key、Session ID/Cookie、IPsec selector 和接口绑定。

udp port 1701 只能捕获使用该端口的 L2TPv3 UDP 报文；静态 session 可以配置其他端口。加密后 WAN 上不会再看到明文 ip proto 47/UDP 4789，应在 XFRM 前后合适的接口或策略点抓取。

16.3 第 3 层：隧道和 Bridge 状态

bash 复制代码

ip -d link show dev vxlan123
ip -s link show dev vxlan123
bridge link show
bridge fdb show br br123
bridge vlan show

关注：接口是否 UP；是否真的是 master br123；VLAN PVID/tagged membership 是否匹配；STP 是否处于 forwarding；RX/TX/drop/error 是否变化；远端 MAC 是落在 tunnel 还是错误地落在 LAN。

对 L2TPv3：

bash 复制代码

ip l2tp show tunnel
ip l2tp show session
ip -s link show dev l2tpeth123

对 IPsec：

bash 复制代码

ip xfrm state
ip xfrm policy
ip -s xfrm state

观察 SA 是否存在、selector 是否匹配、包/字节计数是否双向增长、replay/integrity error 是否增加。IKE"已连接"但 CHILD_SA selector 不匹配时，业务仍会走明文或被策略丢弃。

16.4 第 4 层：直接看内层 Ethernet

bash 复制代码

tcpdump -eni br123 arp
tcpdump -eni lan0 arp
tcpdump -eni vxlan123 arp

应看到 A 的 ARP Request 源 MAC/IP 正确、目的 MAC 为广播，并在远端 Bridge 出现；随后 B 的 Reply 应为单播返回。若 Request 到达 B 但没有 Reply，查 B 的掩码、VLAN、主机防火墙、NIC、ARP 策略；若 Reply 到达 tunnel 却不出 LAN，查 Bridge FDB/STP/VLAN。

清空动态 FDB 可以辅助复现实验，但会瞬间触发重新泛洪，生产环境应谨慎并限定对象。优先观察而不是先删除状态。

16.5 症状到证据的映射

症状	优先检查	关键证据
两端隧道 IP 可 ping，业务完全不通	Bridge membership、VLAN、VNI/Session	`bridge link/vlan/fdb`、内层 ARP 抓包
小包通，大包/TLS 卡住	PMTU、DF、ICMP、叠加安全开销	`tracepath`、DF 二分探测、ICMP too-big 抓包
首包慢，之后正常	ARP/FDB 首次学习、BUM 路径	ARP 时序、全零 VXLAN FDB、MAC 学习时间
单向通	回程路由/NAT、反向 SA、FDB 指向	两端同步抓包、`ip route get`、XFRM 计数
每隔几十秒/几分钟中断	NAT idle timeout、rekey、FDB ageing	keepalive、IKE 日志、FDB 状态时间线
MAC 在两个端口跳动	二层环路、双归未正确处理	MAC move 日志、STP port state、重复帧
CPU 高而带宽不高	小包/BUM、用户态加密、offload 未命中	pps、softirq、OpenVPN CPU、`ethtool -S`
VXLAN 外层可见，远端不解封	UDP port/VNI/local address/checksum	`ip -d link`、远端抓包、NIC offload 对比

一个可靠的验收闭环应同时满足：外层双向计数增长；内层 ARP Request/Reply 完整；FDB 学习方向正确；目标业务单双向成功；最大业务 packet 不碎片/不黑洞；故障切换和恢复不会产生环路。

17. 常见误区与不该使用大二层的场景

17.1 十个常见误区

"VXLAN 就是加密隧道。" 错。VXLAN 定义二层 over UDP；要用 IPsec/WireGuard 等另行保护。
"GRE 用 TCP/UDP 47 端口。" 错。GRE 是 IP protocol 47，没有端口。
"GRE 不能传二层。" 说法过度。普通 Linux gre 多用于三层；GRETAP 使用 Transparent Ethernet Bridging 类型承载 Ethernet。
"GRE key 是密码。" 错。它用于区分上下文，不提供保密、认证或完整性。
"L2TPv3 就是家用 L2TP/IPsec VPN。" 错。这里讨论的是 Pseudowire 与 Ethernet session。
"UDP 天然能穿所有 NAT。" 错。对称 NAT、CGNAT、映射超时、静态对端和回程仍会失败。
"把 MTU 改成 1400 就稳了。" 错。开销取决于协议栈；盲目降 MTU 既可能仍太大，也可能浪费带宽。
"MSS clamp 解决了 MTU。" 错。它只影响 TCP，不能修复其他帧。
"开了 STP 就不会环路。" 错。BPDU 必须按预期穿越/终止，所有设备模式要兼容，并需实际演练。
"端点能 ping 就说明大二层成功。" 错。Ping 通常只验证 Underlay 的某条三层路径。

17.2 明确不应延伸二层的场景

业务只需要访问 API、数据库、Web 或其他明确的 IP 服务；
想用大二层掩盖错误的地址规划、缺失的 DNS/服务发现或不愿修改静态 IP；
跨高时延、低带宽、易抖动公网，却没有 BUM 基线、限速和环路控制；
两端安全等级不同，桥接后会绕过现有三层防火墙/微分段；
广播域内设备数量和 MAC churn 很高，而 FDB/control plane 容量未知；
依赖"VM 跨城热迁移"却没有同步考虑存储一致性、应用会话、默认网关、延迟和故障域；
团队没有能力观察 Underlay、隧道、Bridge、FDB、STP、MTU 和加密状态。

可替代方案通常更稳健：三层路由/动态路由、VRF、IPsec/WireGuard L3 VPN、应用层负载均衡、DNS/服务注册、数据库/存储复制、DHCP relay、mDNS gateway，或由运营商提供边界清晰的 L2VPN。

总结

大二层的本质很简单：让 Ethernet frame 借助可路由的 Underlay 到达另一个 Bridge。真正困难的是围绕这帧建立一套可运营系统：谁发布远端 MAC、BUM 向谁复制、环路如何收敛、PMTU 如何证明、NAT 如何维持、安全由哪一层提供、失败时能否逐层观察。

如果只有两个可控 Linux 端点，GRETAP 或静态 L2TPv3 可以很直接；如果需要把加密和少量客户端接入合并，OpenVPN TAP 有其位置；如果面向多站点、多租户和长期扩展，VXLAN 与 EVPN 的组合更自然。无论选哪一种，先证明"必须二层"，再把广播域缩到最小，通常比寻找一个更炫的隧道协议更重要。

大二层组网技术详解：VXLAN、GRETAP 等

先给结论

目录

1. 先把三个平面分开

1.1 "同一二层"究竟意味着什么

1.2 点到点和多点是两类不同问题

2. 一帧 ARP 如何跨过 WAN

3. VXLAN：规模化 Overlay 的主力

3.1 封装到底增加了什么

3.2 FDB 学习和 BUM 复制

3.3 VXLAN 的适用与边界

4. GRE 与 GRETAP：简单直接的点到点二层

4.1 GRETAP 与 IPsec 的职责分工

5. OpenVPN TAP：把二层桥接放进加密 VPN

5.1 为什么有人选择 TAP

5.2 TAP 的代价

6. L2TPv3：以 Pseudowire 承载 Ethernet

6.1 两种承载方式

6.2 Linux 的"静态 L2TPv3"没有替你做什么

7. 其他相关技术

7.1 EtherIP

7.2 GENEVE

7.3 EVPN 与 VPLS

7.4 ZeroTier

8. BUM、FDB 与规模边界

8.1 四种重点技术怎样处理 BUM

8.2 抑制 BUM 的正确顺序

9. STP、环路与故障域

9.1 STP 并不会因为存在隧道就自动生效

9.2 防环应采用多层约束

10. MTU：先明确从哪一层开始计算

10.1 常见最小开销表

10.2 一个有条件成立的数值示例

11. NAT、CGNAT 与防火墙

11.1 上线前至少确认这些问题

12. 怎样给大二层加密

12.1 VXLAN over IPsec

12.2 Overlay over WireGuard

12.3 L2TPv3 over IPsec

13. 四种重点方案的 Linux 实战

13.1 实验一：两点静态 VXLAN

13.2 实验二：两点 GRETAP

13.3 实验三：OpenVPN TAP 与 Linux Bridge

13.4 实验四：静态 L2TPv3 Ethernet Session

14. 性能、可用性与安全设计

14.1 不要只看"最高吞吐"

14.2 数据路径和卸载能力

14.3 可用性不是多建一条隧道

14.4 安全威胁模型

15. 对比表与选型决策树

15.1 四种重点方案工程对比

15.2 扩展方案定位

15.3 决策树

16. 分层抓包与排障

16.1 第 1 层：Underlay 与策略

16.2 第 2 层：最外层报文是否发出和到达

16.3 第 3 层：隧道和 Bridge 状态

16.4 第 4 层：直接看内层 Ethernet

16.5 症状到证据的映射

17. 常见误区与不该使用大二层的场景

17.1 十个常见误区

17.2 明确不应延伸二层的场景

总结