[Feature Request] 建议增加按目标节点指定传输通道（P2P/中继）的功能

[NANAN-BOY]

这个功能请求是否与某个问题相关？请描述。

目前，VNT 通过 --relay-only（或 --use-channel relay）等参数支持全局通道选择，默认则为自动协商。但目前无法针对单个目标节点单独指定传输通道（P2P 直连或中继转发）。

在实际场景中，这种灵活性很有必要：

某个特定节点（如 10.26.0.1）可能位于严格的防火墙后面（出口丢弃UDP包，导致打洞成功但网络几乎无法联通，vnt目前也不会对这种情况检测并切换），只能通过中继服务器访问。

而其他节点（如 10.26.0.2、10.26.0.3）则在同一局域网内，P2P 直连质量很好。

如果全局启用 --relay-only，所有流量都会走中继，这会不必要地增加延迟，并给中继服务器增加额外的负载。反之，如果不启用，则问题节点可能无法连接或连接不稳定。

描述你期望的解决方案

我希望 VNT 能支持客户端为单个目标节点指定首选或强制的传输通道（P2P 或中继）。

可能的实现方式：

命令行按节点参数：例如 --peer-channel <节点IP>=<relay|p2p|auto>

扩展路由表：在现有的路由表（--route）中增加通道类型字段

配置文件支持：在 vnt.yml 或类似配置文件中为每个节点指定通道偏好

示例：
text

vnt-cli --peer-channel 10.26.0.1=relay --peer-channel 10.26.0.2=p2p

描述你考虑过的替代方案

目前的变通方案是使用全局 --relay-only 参数，但这会强制所有流量经过中继服务器，会降低与 P2P 连接良好的节点之间的性能，同时浪费中继服务器的带宽。

另一个替代方案是手动重启客户端并切换参数，但这很不方便，而且会中断现有连接。

补充背景信息

从 --route 命令的输出可以看到，我的设备与不同节点之间同时存在多种连接路径（有些是通过 TCP 中继 tcp@103...11:*****(HongKong)，有些是通过 P2P 直连 192.168.5.x:xxxxx）(Mainland)。这说明底层架构已经具备同时管理多个通道的能力，将其扩展为允许用户按节点指定通道偏好，在技术上是可行的。

这个功能将大大增强 VNT 在混合网络环境（如家庭/办公 VPN、物联网部署）中的灵活性，让用户能针对不同节点兼顾稳定性和性能。

感谢开发者

[FishBossTca]

通过多个 in_ips 让节点充当中继

可以通过为节点配置多个 in_ips，让一个节点同时负责转发多个受限节点之间的流量，从而实现不经过服务器中继的节点间通信。

1. 网络环境

假设存在以下节点：

节点	虚拟地址	内网地址	网络情况
服务器	192.168.11.1	—	公网/中心节点
设备 A	192.168.11.2	192.168.1.2	网络正常，可连接 B、C
设备 B	192.168.11.3	192.168.2.3	只能连接 A
设备 C	192.168.11.4	192.168.3.4	只能连接 A

网络可达关系如下：

                 ┌──────────────┐
                 │   设备 A     │
                 │ 192.168.11.2 │
                 │ 192.168.1.2  │
                 └──────┬───────┘
                        │
              ┌─────────┴─────────┐
              │                   │
              ▼                   ▼
       ┌──────────────┐    ┌──────────────┐
       │   设备 B     │    │   设备 C     │
       │ 192.168.11.3 │    │ 192.168.11.4 │
       │ 192.168.2.3  │    │ 192.168.3.4  │
       └──────────────┘    └──────────────┘

       B ⇄ A
       C ⇄ A
       B ✕ C

也就是说：

• A ↔ B：可直连
• A ↔ C：可直连
• B ↔ C：无法直连

---

2. 让设备 A 充当中继

如果希望 B 和 C 可以直接使用彼此的内网地址进行通信，可以让设备 A 充当中继。

数据路径变为：

设备 B
  │
  │ 访问 192.168.3.4
  ▼
设备 A
  │
  │ 中继转发
  ▼
设备 C

反方向同理：

设备 C
  │
  │ 访问 192.168.2.3
  ▼
设备 A
  │
  │ 中继转发
  ▼
设备 B

因此实际的数据路径是：

B ──────► A ──────► C
B ◄────── A ◄────── C

这里的关键点是：

服务器只负责节点建立连接，B 和 C 之间的数据可以通过 A 进行中继，而不需要经过服务器。

---

3. 节点配置

前提条件：

• 所有节点的 out_ips 均设置为 0.0.0.0/0
• 所有节点的操作系统均开启 IP 转发
• A 能够正常访问 B 和 C
• B、C 均能够访问 A

设备 A

A 需要知道：

• 192.168.2.3 可以通过 B 访问
• 192.168.3.4 可以通过 C 访问

in_ips:

192.168.2.3/32,192.168.11.3
192.168.3.4/32,192.168.11.4

也就是：

192.168.2.3 ──► 192.168.11.3 (设备 B)
192.168.3.4 ──► 192.168.11.4 (设备 C)

设备 B

B 无法直接访问 C，因此将访问 192.168.3.4 的流量交给 A：

in_ips:

192.168.3.4/32,192.168.11.2

即：

192.168.3.4 ──► 192.168.11.2 (设备 A)

设备 C

C 同理，将访问 192.168.2.3 的流量交给 A：

in_ips:

192.168.2.3/32,192.168.11.2

即：

192.168.2.3 ──► 192.168.11.2 (设备 A)

---

4. 最终形成的路由关系

配置完成后，可以理解为形成了下面这样的逻辑拓扑：

                 ┌─────────────────┐
                 │     设备 A      │
                 │  192.168.11.2   │
                 │                 │
                 │     中继节点     │
                 └───────┬─────────┘
                         / \
                        /   \
                       /     \
                      ▼       ▼
             ┌──────────┐   ┌──────────┐
             │  设备 B  │   │  设备 C  │
             │ .11.3    │   │ .11.4    │
             │ .2.3     │   │ .3.4     │
             └──────────┘   └──────────┘

             B ──► A ──► C
             C ──► A ──► B

因此最终可以实现：

发起节点	目标地址	实际路径
A	192.168.2.3	A → B
A	192.168.3.4	A → C
B	192.168.3.4	B → A → C
C	192.168.2.3	C → A → B

5. 最终效果

配置完成后：

设备 B
192.168.2.3
    │
    │ 访问 192.168.3.4
    ▼
设备 A
192.168.1.2
    │
    │ 中继
    ▼
设备 C
192.168.3.4

因此：

B → 192.168.3.4  ✓

C → 192.168.2.3  ✓

A → 192.168.2.3  ✓
A → 192.168.3.4  ✓

核心思路就是：

in_ips 不仅可以描述“这个地址属于哪个节点”，还可以利用它指定“访问这个地址时应该通过哪个节点转发”，从而让网络条件较好的节点充当其他节点之间的中继。**

[NANAN-BOY]

这个思路很巧妙，用 in_ips 做路由劫持来绕开中继服务器，确实能解决眼下部分节点受限的问题，感谢分享！

不过从长远看，如果能在“虚拟机房”这类高吞吐场景下，让两个非墙异地节点之间自动走 P2P 直连，延迟和带宽都会比经过中间节点转发好很多。还是希望官方后续能把按节点指定通道的功能安排上，这样灵活性和性能就都能兼顾了。再次感谢！
若指定节点固定协议影响VNT架构/灵活性，可以退一步 两点之间指定：中继/自动 也可以，这样依旧可以解决UDP跨墙丢包的问题。