我有一个自然而然的合理需求，我在自己的 PC 上运行 Clash Meta 的 TUN 模式，又想同时使用蒲公英或者 n2n 这类虚拟局域网软件进行远程局域网联机游戏，我很好奇者是否能够共存？
或者更进一步，如果 Clash Meta 是在上游的路由器上运行的 TUN 模式，而贝锐蒲公英在下游的设备上运行，是否也能实现共存？本文将对此进行探讨。

路由表基础：网络世界的交通指南

在深入探讨之前，先理解路由表的基础知识是非常必要的。这有助于我们明白这些工具是如何影响网络流量走向的。

想象一下，我们的电脑或手机就像一个城市里的地址，而互联网就像一个连接着无数城市的庞大交通网络。当我们想从自己的“地址”发送信息（数据包）到另一个遥远的“地址”（例如访问一个网站服务器）时，数据包需要在复杂的网络中找到正确的路径。这时，路由表 (Routing Table) 就扮演了至关重要的角色，它就像是网络世界的“导航地图”或“交通指挥中心”。

什么是路由表？

简单来说，路由表是操作系统内核（或者路由器内部）维护的一个数据库或列表。它包含了一系列的路由条目 (Route Entries)。每一条路由条目都规定了：如果要将数据包发送到某个特定的目的地网络或主机，那么下一步应该将这个数据包交给谁（下一跳网关 Next Hop Gateway），并且应该从哪个网络出口（网络接口 Network Interface） 发送出去。

路由表的作用

路由表的核心作用是指导 IP 数据包的转发决策 (Forwarding Decision)。当你的电脑需要发送 IP 数据包，或者路由器收到一个需要转发的数据包时，它会执行以下步骤：

1. 提取数据包中的目标 IP 地址。
2. 查询路由表，寻找能够匹配这个目标 IP 地址的路由条目。
3. 查找规则：最长前缀匹配 (Longest Prefix Match)。如果有多条路由规则都能匹配目标 IP（例如，一条指向具体子网的规则和一条默认路由规则都能匹配某个公网 IP），系统会选择描述网络范围最精确的那一条规则（即子网掩码最长的那条）。

   这里的优先级非常重要，因为它决定了数据包的转发路径。具体见下文，简单来说就是子网掩码最优先。

4. 根据选中的路由条目所指示的下一跳网关和输出接口，将数据包转发出去。

如果路由表中找不到任何匹配的特定路由规则，系统就会使用默认路由 (Default Route)，将数据包发送给默认网关 (Default Gateway)（通常是你连接的路由器），让它来处理后续的转发。没有路由表，设备之间基本上只能在同一个局域网段内进行通信。

如何查看路由表

查看路由表通常需要使用命令行工具：

• Windows:route print 或 netstat -r。

• macOS:netstat -rn

• Linux:ip route show（推荐） 或 route -n（旧式） 或 netstat -r（旧式）。

路由的种类

路由表中的条目根据其来源和特性，可以大致分为几类：

1. 直连路由 (Directly Connected Route) / 接口路由 (Interface Route):

   • 当你给电脑的网络接口（如以太网卡、Wi-Fi 网卡、虚拟网卡）配置 IP 地址和子网掩码时，操作系统会自动生成指向该接口所连接的整个本地子网的路由。
   • 这种路由的“网关”通常是 在链路上 (On-link) 或接口自身的 IP，表明可以直接通过该接口访问目标网络，无需经过路由器转发。

2. 静态路由 (Static Route):

   • 由网络管理员或用户手动配置的固定路由规则。
   • 除非被手动删除或相关网络接口失效，否则它会一直存在于路由表中。
   • 适用于网络拓扑稳定，需要明确指定路径的场景。默认路由通常就是一条静态路由，指向默认网关地址。

3. 动态路由 (Dynamic Route):

   • 路由器之间通过运行动态路由协议（如 RIP、OSPF、BGP 等）互相学习网络拓扑信息，并自动生成和更新路由条目。
   • 能够自动适应网络变化，但配置和管理相对复杂。
   • 主要用于大型企业网络或互联网骨干网。个人电脑上一般不会直接参与动态路由协议（除非安装了特定软件）。

路由决策的优先级：计算机如何选择路径？

下一个关键问题是：当有多条路径都可能到达目的地时，计算机（或路由器）是怎么决定到底走哪一条路的呢？这个决策过程并非随机，而是遵循着清晰的优先级规则，以确保效率和准确性：

1. 第一原则：最长前缀匹配 (Longest Prefix Match) / 最精确路由优先

   • 这是路由选择中最根本、最优先的规则。操作系统会用数据包的目标 IP 地址，去和路由表中所有路由条目的“网络目标”及“网络掩码”（或称子网掩码）进行比对。
   • 可能会有多条路由规则都能“匹配”这个目标 IP（例如，一个公网 IP 同时符合某个大型网络区块的路由和默认路由）。在这种情况下，系统必定会选择网络掩码最长（也就是描述的网络范围最小、最精确）的那一条路由规则。
   • 示例： 如果路由表里同时有针对 192.168.1.0/24 和 0.0.0.0/0 (默认路由) 两条规则。当目标是 192.168.1.100 时，虽然两条规则都能匹配，但 /24 的前缀长度比 /0 更长、更精确，所以系统必定选择 192.168.1.0/24 这条规则。默认路由只有在找不到任何更具体的匹配时才会被使用。
   • 这个原则确保了流量总是会优先走已知的、最明确的路径。

2. 第二原则：度量值 (Metric) / 成本最低优先 (当最长匹配相同时)

   • 只有在一种相对特殊的情况下，也就是路由表中存在多条具有完全相同的最长前缀长度、且都能匹配目标 IP 的路由规则时（最常见的例子就是设置了多个默认路由，它们的前缀长度都是 /0），“最长前缀匹配”原则就无法分出胜负了。
   • 这时，系统才会启用第二个判断标准：比较这些规则的度量值 (Metric)，也就是我们之前介绍的“跃点数”或路由“成本”。
   • 系统会选择Metric 值最低的那条路由规则。Metric 值越低，代表系统认为走这条路的“成本”越低（可能更快、更可靠或被管理员指定为更优先），因此优先选择。

“在链路上 (On-link)”的角色

路由表中标记为“在链路上 (On-link)”的路由，通常代表的是与本机网络接口直接相连的本地子网（即直连路由）。这本身就是到达该子网内所有主机的最直接、最精确的路径。因此，这类路由（通常是 /24, /16 等具体子网）根据“最长前缀匹配”原则，自然会比默认路由 (/0) 优先。同时，操作系统通常也会为这些直连路由指派非常低的 Metric 值，进一步巩固了它们在处理本地局域网流量时的最高优先地位。

总结决策流程：

所以，计算机或路由器决定数据包路径的完整逻辑可以简化为：

1. 找出路由表中所有能“匹配”目标 IP 的路由规则。
2. 从中挑选出具有最长网络掩码（最精确）的那一条或多条规则。
3. 如果只有一条最精确，就选它。
4. 如果恰好有多条规则都具有相同的最长掩码（例如都是默认路由 /0），则再从中挑选出 Metric 值最低（成本最低）的那一條规则。
5. 依照最终唯一选定的规则指示（下一跳网关和输出接口），将数据包发送出去。

理解了路由表如何工作以及不同类型的路由，我们就能更好地把握 Clash Meta TUN 模式或虚拟局域网软件是如何通过添加、修改路由表中的规则来“指挥”网络流量，实现其各自功能的了。推荐观看。

Clash Meta Tun 模式原理

Clash Meta 是一个功能强大的网络代理工具。 其 TUN 模式旨在提供系统级的透明代理能力，能够处理包括 TCP、UDP 和 ICMP 在内的多种网络流量。下面简述其工作原理：

1. 虚拟网络接口创建：TUN (Tunnel) 模式 通过创建一个虚拟网络接口（通常在 Linux/macOS 上表现为 tunX 设备，Windows 上依赖 wintun.dll 创建虚拟网卡）来实现其功能。这个虚拟接口工作在 网络层（Layer 3），主要处理 IP 数据包。Clash Meta 通过这个接口接收和发送网络流量。

2. 流量处理与路由：启用 TUN 模式后，特别是当 auto-route 选项被设置为 true 时，Clash Meta 会尝试修改操作系统的路由表和路由规则。其目标是将系统的默认路由指向 Clash 创建的 TUN 虚拟接口，从而强制大部分（或全部）出站网络流量流经 Clash 进行处理。Clash 根据其配置文件中的规则（基于域名、GEOIP、IP CIDR、进程名等）决定流量是直接连接（DIRECT）、拒绝（REJECT）还是通过指定的代理节点转发。由于需要修改系统路由表等底层网络设置，启用 TUN 模式通常需要管理员或超级用户权限。

   # macOS 路由表的一部分，可以看出 Clash Meta 的 TUN 模式创建了一个虚拟网卡（utun8），并添加了多个路由条目。
   ❯ netstat -rn
   Routing tables
   
   Internet:
   Destination        Gateway            Flags               Netif Expire
   default            192.168.31.1       UGScg                 en0
   default            link#29            UCSIg           bridge100      !
   default            link#31            UCSIg           bridge101      !
   1                  198.18.0.1         UGSc                utun8
   2/7                198.18.0.1         UGSc                utun8
   4/6                198.18.0.1         UGSc                utun8
   8/5                198.18.0.1         UGSc                utun8
   16/4               198.18.0.1         UGSc                utun8
   32/3               198.18.0.1         UGSc                utun8
   64/2               198.18.0.1         UGSc                utun8
   127                127.0.0.1          UCS                   lo0
   127.0.0.1          127.0.0.1          UH                    lo0

3. DNS 处理：Clash Meta 内建了 DNS 服务器功能，旨在减少 DNS 污染的影响。在 TUN 模式下，可以通过 dns-hijack 选项拦截系统或特定地址的 DNS 查询。当启用 enhanced-mode: fake-ip 时，Clash DNS 会为匹配代理规则的域名返回一个位于特定范围（如 198.18.0.1/16）内的“假 IP 地址”。Clash 随后根据这个假 IP 将流量路由到对应的代理策略。

   因此在 TUN 模式打开时，使用 dig 或 nslookup 等工具查询 DNS 时，会得到 Clash 的假 IP 地址，而不是实际的 DNS 解析结果。
   包括使用 ping 命令时，返回的 IP 地址也会是 Clash 的假 IP 地址，响应时间会非常快，通常小于 1ms，就是由于 ICMP 请求被 Clash 的 TUN 模式直接处理了，Clash 作为最终的接收者，直接返回了假 IP 地址的响应。

4. 协议栈选项：Clash Meta TUN 模式提供了不同的底层 TCP/IP 协议栈实现，主要包括 system 和 gvisor。system 栈通常性能更好，直接利用操作系统的网络栈处理数据包，而 gvisor 是 Google 开发的用户空间协议栈，可能提供更好的隔离性或兼容性，但可能带来性能损耗。部分实现还提供了 mixed 模式，结合两者优势。

虚拟局域网软件（如蒲公英/N2N）工作原理

在了解了 Clash Meta TUN 模式之后，我们来看看像贝锐蒲公英 (Pgy) 或 N2N (以及类似 ZeroTier, Tailscale 等) 这类虚拟局域网软件是如何工作的。它们的核心目标是将地理上分散的设备连接起来，使它们感觉就像在同一个本地局域网中一样，从而方便文件共享、远程桌面、联机游戏等。其基本原理涉及以下几个关键点：

1. 虚拟网络接口与私有 IP 分配： 与 Clash Meta TUN 类似，这类软件也会在每台加入虚拟网络的设备上创建一个虚拟网络接口。这个接口会被分配一个来自特定私有 IP 地址段的 IP，例如 10.230.232.x、5.x.x.x (蒲公英常用) 或其他自定义范围。网络中的所有成员都会获得这个范围内的唯一 IP 地址。从应用程序的角度来看，这些远端的机器就像拥有了一个可以直接访问的本地 IP 一样。

2. 特定路由的添加： 这是实现“局域网”效果的关键一步。虚拟局域网软件会自动修改操作系统的路由表，添加一条或多条非常具体的路由规则，将目标地址指向其分配的私有 IP 地址段的流量，全部导向它自己创建的那个虚拟网络接口。例如，它会添加类似这样的路由：

   # Windows 路由表示例，假设 10.230.232.145 是本机虚拟网卡 IP
   网络目标        网络掩码          网关         接口    跃点数
   10.230.232.0    255.255.255.0     在链路上    10.230.232.145   291

   这条规则的精确度（/24）高于默认路由（/0），因此，任何发往 10.230.232.x 的流量都会被操作系统根据最长前缀匹配原则，优先交给这个虚拟网络接口处理，而不会发送给物理网络的默认网关（如家中的路由器）。这就是为什么访问虚拟局域网内部 IP 的流量，看起来像是“本地处理”的原因。

3. 封装与隧道技术 (Encapsulation & Tunneling)： 当操作系统将目标为虚拟网络伙伴（例如 10.230.232.77）的数据包交给虚拟接口后，虚拟局域网软件就接管了。它知道这个目标 IP 对应的设备在物理上位于远端。为了让数据包能够穿过互联网到达对方，软件会将原始的数据包（源 10.x, 目标 10.x，我们称之为内层包或载荷包 Payload Packet）进行封装 (Encapsulation)，将其作为数据负载放入一个新的外层数据包 (Outer Packet) 中。这个外层包使用设备的真实公网 IP 地址（或经过 NAT 转换后的地址）作为源和目标（或者通过中继服务器），通常使用 UDP 协议进行传输，因为它更容易穿越 NAT。这个封装并通过公共网络传输的过程，本质上就是建立了一条隧道 (Tunnel)。远端的虚拟局域网软件收到外层包后，会进行解封装 (Decapsulation)，提取出原始的内层包，再注入到接收端操作系统的网络栈中，完成通信。

4. 节点发现与连接建立 (Peer Discovery & Connection Establishment)： 为了知道外层包应该发往哪个公网 IP 地址，虚拟局域网软件需要一套机制来发现其他成员的公网位置并建立连接。这可能通过：

   • 中心服务器 (Coordinator/Supernode)：设备向中心服务器注册、上报状态并查询其他成员的地址信息（蒲公英等商业方案常用）。中心服务器也可能帮助进行 NAT 穿透（打洞）。
   • 分布式哈希表 (DHT)：一种去中心化的 P2P 发现机制（N2N 使用）。
   • NAT 穿透与中继 (NAT Traversal & Relaying)：软件会尝试使用 STUN/TURN/ICE 等技术在 NAT 设备后建立直接的 P2P 连接。如果“打洞”失败，流量可能需要通过服务商提供的中继服务器 (Relay Server) 进行转发，这通常会增加延迟。

5. 数据安全 (Data Security)： 为了保护通信内容，通过隧道传输的数据通常都会进行端到端加密 (End-to-End Encryption) 处理，即使流量经过中继服务器，也只有通信的双方能够解密原始数据，确保了通信的私密性和完整性。

Clash Meta TUN 与虚拟局域网软件的共存

理解了 Clash Meta TUN 和虚拟局域网软件各自的原理——前者主要通过修改默认路由（或添加大量覆盖公网的特定路由）来接管大部分出站流量并进行代理分流，后者通过添加特定路由来处理内部虚拟局域网流量并使用封装隧道技术进行跨网传输——我们现在可以来分析它们共存的可能性了。

先说结论：通常情况下，它们是可以良好共存的，这主要得益于 IP 路由的最长前缀匹配原则以及虚拟局域网的封装机制。我们分两种常见场景来讨论：

场景一：Clash Meta TUN 与 N2N/蒲公英均运行于本机 PC

这是许多用户可能会遇到的情况，希望在本机同时享受透明代理和虚拟局域网带来的便利。

1. 路由配置：

   • Clash Meta TUN 启动后，会创建虚拟网卡（如 utunX 或 Meta Tunnel），并修改路由表，通常是添加一个 Metric 值极低的默认路由（0.0.0.0/0）指向其虚拟网卡，或者添加大量覆盖公网 IP 的特定路由（如 /1, /2, /3 等），目的是捕获所有发往“外部”的流量。
   • N2N 或蒲公英启动后，也会创建自己的虚拟网卡，并添加指向其虚拟局域网私有 IP 段的特定路由（例如 10.230.232.0/24 via On-link Interface 10.230.232.145）。

2. 流量处理：

   • 访问虚拟局域网内部 IP (例如 10.230.232.77)：

     • 当你的 PC 访问 10.230.232.77 时，操作系统查询路由表。
     • 根据“最长前缀匹配”原则，10.230.232.0/24 这条路由比 Clash Meta 设置的默认路由 (/0) 或公网路由 (/1, /2 等) 更精确。
     • 因此，操作系统必定选择 N2N/蒲公英添加的这条特定路由，将流量直接交给 N2N/蒲公英的虚拟网络接口处理。
     • 结论：这部分流量完全由 N2N/蒲公英软件在本地处理（如果是发往远端节点，则由它进行封装），完全绕过了 Clash Meta 的 TUN 接口和规则。内部虚拟局域网通信不受影响。

   • 访问公网 IP 或未被 N2N 路由覆盖的 IP (例如 8.8.8.8 或远端节点的公网 IP)：

     • 当 N2N/蒲公英需要将封装后的外层包（目标是远端节点的公网 IP）发送出去时，或者当你的其他应用程序直接访问互联网（如 8.8.8.8）时，操作系统会再次查询路由表。
     • 此时，没有比 Clash Meta 设置的路由（无论是 Metric=0 的默认路由还是覆盖公网的特定路由）更精确的规则了。
     • 因此，这些外层包或普通公网访问流量会被路由到 Clash Meta 的 TUN 虚拟接口。
     • 结论：Clash Meta 会接管这些流量，并根据你配置的 Clash 规则（针对外层包的目标公网 IP 或 8.8.8.8 等）来决定是 DIRECT（直连，此时 Clash Meta 会参考系统的次优路由，通常是物理网卡的默认路由）、PROXY（走代理）还是 REJECT。

   • 总结 (场景一)：在本机共存是完全可行的。虚拟局域网内部流量因路由精确匹配而由对应软件处理，不受 Clash Meta 影响。而虚拟局域网与外部通信的流量（已被封装）以及其他所有公网流量，则会被 Clash Meta 接管并按规则处理。

场景二：Clash Meta TUN 在上游路由器，N2N/蒲公英在下游 PC

这种情况也很常见，例如在软路由上部署 Clash Meta 实现整个局域网的透明代理，而某台 PC 需要加入虚拟局域网。

1. 路由配置：

   • PC 端：N2N/蒲公英在 PC 上运行，创建虚拟网卡并添加指向虚拟局域网 IP 段的特定路由（如 10.230.232.0/24）。PC 的默认网关指向上游路由器。PC 上没有运行 Clash Meta TUN。
   • 路由器端：Clash Meta 在路由器上运行 TUN 模式，修改了路由器的路由表，将大部分（或全部）离开局域网发往互联网的流量都导向 Clash Meta 处理。

2. 流量处理：

   • PC 访问虚拟局域网内部 IP (例如 10.230.232.77)：

     • 与场景一完全相同。PC 操作系统根据本地路由表中的特定路由 (10.230.232.0/24)，将流量交给 N2N/蒲公英的虚拟接口在本地处理。
     • 结论：流量根本不会离开 PC 发往上游路由器，因此上游路由器的 Clash Meta 完全不感知、不影响这部分内部通信。

   • PC 通过 N2N/蒲公英访问远端节点 或 PC 直接访问公网：

     • 对于 N2N/蒲公英的封装流量：N2N/蒲公英软件将内层包封装成外层包（目标是远端节点的公网 IP）。PC 操作系统路由这个外层包，发现没有特定路由匹配，于是使用默认路由，将其发往上游路由器。
     • 对于 PC 的普通公网访问流量：PC 操作系统发现没有特定路由匹配，使用默认路由，将其发往上游路由器。
     • 路由器处理：上游路由器收到来自 PC 的数据包（无论是 N2N 封装的外层包，还是普通的公网访问包）。路由器上的 Clash Meta 会拦截这些流量。
     • 结论：路由器上的 Clash Meta 会根据它自己的规则（匹配外层包的目标公網 IP，或普通訪問的目標 IP/域名）来处理这些流量（DIRECT, PROXY, REJECT）。

   • 总结 (场景二)：这种架构下共存通常更“干净”且符合逻辑。虚拟局域网内部流量完全在 PC 本地解决。所有需要离开 PC 的流量（包括 N2N 封装后的流量和普通上网流量）都会自然地汇聚到上游路由器，由路由器上的 Clash Meta 统一根据其策略进行处理。

潜在的细微问题 (两种场景共通)：

• DNS 处理：如果 Clash Meta（无论在本机还是上游）使用了 Fake-IP 模式，并且 N2N/蒲公英软件需要通过域名连接其中央服务器或 P2P 节点，需要确保 Clash Meta 的规则正确处理了这些域名（例如设置为 DIRECT），以避免连接问题。
• UDP 流量：游戏联机和某些虚拟局域网软件（如 N2N）大量使用 UDP。需要确保 Clash Meta 的配置（以及所选的代理协议）能够良好地支持 UDP 转发。如果代理节点对 UDP 支持不佳或完全不支持，可能会导致连接失败或性能低下。
• 性能：在本机同时运行两者会消耗更多 CPU 和内存资源。如果 N2N 封装后的流量再经过本地 Clash Meta 的代理，可能会增加额外的延迟。

总而言之，Clash Meta TUN 模式与 N2N/蒲公英这类虚拟局域网软件在路由层面是可以通过优先级规则自然区分流量路径的，实现共存通常没有大的障碍。关键在于理解各自的工作原理以及流量在不同场景下的实际走向。

补充

在实际的实验中，发现蒲公英的路由表项会实时更新，加入/退出都会被通知到小组其他成员实时刷新。 而 N2N 的路由表项是静态的，加入后会将整个网段的路由表项写入你的路由表。

此外注意 windows 默认不允许被 ping，想要查看效果需要在防火墙里允许 icmpin，具体找教程吧