关闭 ARP 会弄坏 VPN 吗？在外层跳上确实会

隧道承载的是 IP 包；加密连接仍然需要本地解析下一跳。请在动态解析与固定条目之间做出选择。

{同一条连接里跑着两个包，它们遵守不同的规则。一个是隧道承载的私有包，虚拟接口处理它时完全不带以太网头。另一个是经接入链路离开主机的加密包，它仍然需要一个本地下一跳，并解析成硬件地址。把两者混为一谈，正是人们关错了接口上的地址解析、随后又纳闷隧道为何始终起不来的原因。}

{包中包，两种投递模型}

{路由模式下的虚拟接口接收 IP 包。它没有以太网头，没有广播域，内部也没有需要解析的地址，因此内层包由隧道自身投递。接入网络上发生的一切，属于另一层投递。}

inner packet: private address -> tunnel device -> the VPN process
outer packet: endpoint address -> access route -> next-hop hardware address

{那个外层包在离开以太网接口时是一个普通的单播帧，它需要下一跳的目的硬件地址。地址解析提供了这个地址，而下一跳通常是本地网关，而不是远端服务器。理解查找对象是网关而非端点，就是诊断的大部分工作。改动任何东西之前，先把两个地址都记下来。}

{找到真正重要的那个邻居}

{先问路由表端点走的是哪个下一跳，再查该跳的邻居表。端点本身很少出现在那里，因为它不在本地链路上。}

ip route get 198.51.100.20
ip neigh show 192.168.0.1

{如果条目存在且可达，外层路径就是好的，故障在别处。如果条目缺失或处于失败状态，该看的就是链路、网关地址，或者阻止解析的策略。无论哪种情况，改隧道上的加密套件设置都帮不上忙。记下邻居表报告的状态字符串，因为它能区分正在进行的尝试与永久失败。}

{学到的条目会掩盖依赖关系}

{缓存条目在创建它的东西消失之后还会继续工作一阵，因此改动几分钟后做的测试可能因为错误的原因而通过。在下结论说解析没有必要之前，要么等条目老化，要么有意把它删掉。}

{反向的错误同样常见：把未解析的条目当成隧道坏掉的证据。实际上它指向本地网段、重复地址，或者一条丢弃了携带应答的帧的端口安全规则。动 VPN 配置之前，先检查交换机端口。}

{把时序当作证据来读。一个解析成功后又反复失效的条目，暗示链路在抖动，或者两台设备在应答同一个地址；而一个从未解析成功的条目，则指向网关地址或接入端口上的过滤。}

{在动态解析与固定条目之间做决定}

{动态解析之所以是默认，是有理由的：网关更换时它会跟着硬件走，也不需要和任何人协调。而当网络是被有意管理的、地址与硬件地址的配对属于有文档记录的设计时，静态条目才是站得住脚的。}

ApproachGood fitCost you accept
Dynamic resolutionLaptops, changing networks, anything with a spare minute to recoverA short outage while the entry is relearned
Permanent entryFixed appliances where the pairing is controlled and recordedA silent failure the day the hardware changes

{无论选哪种，都要把它用在那条承载外层包的接入接口上。在那条接口上关掉解析并不会让隧道更坚固；它剥夺了客户端到达承载隧道的网关的能力，失败看起来就像 VPN 死了，而不是本地地址问题。}

{别忘了另一套协议栈}

{IPv6 并不使用同一形式的地址解析，它用的是邻居发现。分层的问题依然不变：真正的外层包如何到达本地下一跳，又靠什么证明这个答案是当前的。}

{在宣布设计完成之前，也要在另一套协议栈上核对同样两件事，因为承载两个地址族的隧道有两条外层路径要考虑。记下你验证了哪一条、假设了哪一条。}

相关文章